Why Support Workers See "No Shifts" in Care Apps - The Timezone Trap

It is one of the most alarming things a support worker can see: they open the app before a shift, and it says "no shifts today". They know they are rostered. They double check the roster on a laptop and the shift is right there. But the phone insists there is nothing on. In a care setting that confusion is not just annoying, it risks a participant being left without support.

Almost every time, the culprit is not a lost roster or a sync failure. It is a timezone bug. The shift exists in the system exactly as it should. The app has simply calculated the wrong calendar day for it, and then filtered it out of the "today" view. This article explains how that happens, why Australian providers are especially exposed, and the approach that actually removes the problem for good.

Why do shifts show on the wrong day in some apps?

Every date in a rostering system has to be stored somehow, and most modern platforms store times in Coordinated Universal Time (UTC). UTC is a sensible neutral reference: it does not shift for daylight saving and it is the same everywhere in the world. The trouble starts when that stored UTC value has to be turned back into a human calendar day, like "Wednesday the 23rd", so the app can group shifts into a schedule.

To turn a UTC timestamp into a local day you must apply the correct local offset. Australia sits well ahead of UTC. Perth is UTC+8, the eastern states are UTC+10 (or UTC+11 during daylight saving). If the app forgets to apply that offset, or applies the wrong one, the conversion lands on the wrong side of midnight.

Consider a shift that starts at 7:00am on Wednesday at a Perth site. In UTC that same moment is 11:00pm on Tuesday. If the app groups shifts by their raw UTC date, it decides this shift belongs to Tuesday. The worker looks at their Wednesday view and sees nothing. The shift did not disappear; it was filed under the wrong day.

What is the timezone trap in care rostering?

The timezone trap is the assumption that a single date value means the same thing everywhere. It does not. A shift is a moment in time, but "which day is it on" is a local question that depends entirely on where the shift happens.

Care providers hit this harder than most industries for three reasons:

• Shifts happen early and late. Support work runs across mornings, evenings, sleepovers and overnight cover. The edges of the day, just after midnight and just before it, are exactly where a timezone miscalculation flips a shift onto the wrong date.
• Australia is a long way from UTC. An eight to eleven hour offset is large. In the United Kingdom, which sits close to UTC, this bug is often invisible. In Australia it surfaces constantly.
• Providers span multiple time zones. A growing provider might run a Supported Independent Living house in Perth and another in Sydney. Those two sites are two hours apart, and during eastern daylight saving, three. No single organisation-wide setting can be correct for both at once.

How does UTC or server time cause "no shifts today"?

Servers almost always run their clocks in UTC. That is good practice, because it keeps server logs and timestamps consistent no matter where the machine is physically hosted. But it creates a subtle risk: when the code asks "what shifts are on today?", the naive way to answer is to compare each shift's date against the server's current date.

Walk through what that means for an Australian worker. Suppose it is 8:00am on Wednesday in Perth. On the server, running UTC, it is still only midnight, right at the start of Wednesday, or in the eastern states it might still be Tuesday. If the roster query is written as "give me shifts where the date equals the server's today", the server and the worker can disagree about what "today" even is.

Here is the same moment seen three different ways.

Late at night the mismatch runs the other way. At 9:00pm on Wednesday in Sydney it is already 11:00am on Wednesday in UTC, but a shift that starts just after midnight, in the small hours of Thursday local time, may compute as Wednesday in UTC and get pulled into the wrong bucket. Either way, a real shift is filtered out of the list the worker actually looks at.

This is not a rare edge case. It happens every single day, at both ends of the day, for every provider whose app relies on server or UTC time to decide the calendar day. It is one of the reasons frontline staff quietly lose trust in a rostering app and go back to a group chat or a printed sheet, which undoes much of the value of having software at all. It is also why a genuinely mobile-first approach to care management has to get time handling right before anything else.

How should a multi-timezone provider handle this?

The instinct many systems have is to add "a timezone setting" to the organisation. That helps a single-state provider, but it breaks the moment an organisation operates across state lines, which is exactly what happens as providers grow. One setting cannot be simultaneously correct for Perth and for Sydney.

The correct model is to attach a timezone to each client site, not to the organisation as a whole. The logic then becomes:

1. Every client site stores its own timezone, expressed as an IANA zone such as Australia/Perth or Australia/Sydney. IANA zones are the right unit because they encode daylight saving rules automatically, so you never hard-code a fixed offset that breaks in October and April.
2. When a shift needs to be placed on a calendar day, the system converts that shift's start time into the local day of the site where the shift happens.
3. If a particular site has not been given a timezone yet, the system falls back to the company timezone rather than to the server timezone, so there is always a sensible local answer.

With that model, a worker doing a morning shift in Perth has that shift measured in Perth time, and a colleague doing an evening shift in Sydney has theirs measured in Sydney time, even though both shifts live in the same database and both workers use the same app. This is closely related to the wider discipline of multi-site rostering for care providers, where every location has its own operating context that the system has to respect.

How does CareIQ get local time right per site?

CareIQ was built around the principle that a shift's day belongs to the site, not to the server. It stores an IANA timezone against each client site, with a fallback to the company timezone when a site has not set its own. That single design decision removes the entire class of "no shifts" and "wrong day" problems.

When CareIQ builds a support worker's Today and Upcoming lists, it does not compare shift dates against the server clock. Instead it converts every shift to its local day in the relevant site's timezone first, and only then groups shifts into days. A Perth shift is bucketed in Perth time; a Sydney shift is bucketed in Sydney time. The result is that both workers see an accurate schedule, and nothing silently drops off the list.

That same local-time logic flows through the parts of the platform where getting the day wrong would be most damaging:

• The employee dashboard and Today view, so the first thing a worker sees is a true reflection of their day.
• The roster calendar, so shifts appear under the correct date for managers building and reviewing schedules.
• Clock-in grace windows and attendance checks, so a worker is judged on-time against their own local start time rather than a server clock. This matters for accurate GPS clock-in and attendance verification, where a few minutes either way changes the record.
• Dashboard indicators and compliance tiles, so counts of late starts or missed shifts reflect what really happened on the ground.

For a support worker on the road, the payoff is simple: the app tells the truth. Their phone shows the shifts they actually have, on the days those shifts actually fall, whether they are working in Fremantle or Parramatta. That reliability is exactly why frontline staff come to trust an app enough to stop keeping a paper backup, which is the whole point of moving to better rostering practices in the first place.