Daylight Saving Time woes

Hi all,

Today is the day we “spring forward” our clocks in most of the US, that day may be different or nonexistent in your locale, and it’s always changing (for example, last year we here in California voted to stay on Daylight Saving Time permanently year-round, but are waiting for federal approval before implementing it).

I’m working on an app that makes decisions based on the time and the rather naive assumption that a 24-hour day is a constant (on DST days it turns out to be either 23 or 25). Based on my implementation, springing-forward won’t harm my functionality, but falling-back will.

On November 3 at 2 am, it becomes 1 am again. And for an hour my app will make the wrong decisions.

Basically for every event that occurs between 1:00:00 and 1:59:59 I need to be able to determine if it’s the first 1:00-hour or the second 1:00-hour. I can not assume that my app will be running 24/7 so it’s not as simple as polling time and setting a flag when 1:00 rolls around.

I’m struggling to come up with a simple way to determine this without some really crazy underlying engine changes and refactoring the entire way I handle time. That much work might just lead to me abandoning the project. Just wondering if there’s an easy way to figure it out.

Thanks in advance for any ideas!

Untried, but I think TT has something that will help.
What you need is to know the UTC

@Christian Wheel — As hinted by Jeff, UTC is your friend because it does not have DST. You can easily get the current UTC by calling a time server, e.g.

$ sntp 2019-03-10 13:42:18.580328 (-0100) -0.134458 +/- 0.090645 s1 no-leap

and base your calculations on that value. The dates displayed are then just a conversion to local time. There can be a bug in conversion, but at least dates are right at the core.

Conversions are usually made by the OS.

in the far far distant past I solved this problem by checking the difference between the last time my program executed it’s heartbeat timer and the current time it was. In my app this timer fired every second looking for scheduled events to fire off. I saved off the date of the last time it ran, and compared that to the current time. Usually there was a gap of 1 second, sometimes a few seconds if some event took longer to run but if it was more than 45 minutes or so and the time was around the right times in the early morning when the system does this to us I assumed a daylight savings time change. The difference would be positive or negative showing you which way you changed and you can make decisions based on that.

I haven’t touched that code in a very long time, and it functioned fine last night, at least here and I don’t have bug reports flooding in so far this morning :wink: But maybe people are sleeping in :wink: But I am definitely going to file the UTC method of dealing with such things away and revisit that taking that into account. It can still be useful to know when the change actually occurs since you may have to recalculate some offsets or timings and checking every little while for a large change since the last check can give you that.

Unless your app gets held out by the system going to sleep or the bug in current MacOS versions that causes some user space apps to hang when the screen goes to sleep or any other reason it might also be held out for that long… In those cases hilarity will ensue when it wakes up and recalculates everything :wink:

but then, I suppose you could just periodically check the GMTOffset to find out when it changes too… You wouldn’t have to rely on the time when the timer fires but only that value which would only change when the daylight savings changes, or when the person sets the time or changes the location of the computer…

Thank you all for your replies. Unfortunately I don’t know that these solutions will work. I guess I was hoping the Operating System had some sort of flag that was set once DST had fallen back already for the year. Since it’s the OS that changes the clock you’d think they would have made something like this available.

@James Sentman Your solution is a proper approach if you can assume that your application will be running at all times (for server use, etc). I’m sure that many of my users will have their computers off or asleep at times, and I need to pick up the pieces when they return (which could be during either the first or second 1:00 hour).

@Stéphane Mons Likewise I can’t make the assumption that my user has an internet connection to retrieve UTC.

@Jeff Tullin I tried this code and it currently returns a correct value for the UTC offset. But once California’s new always-on-DST goes into effect (possibly later this year), a locale doesn’t exist for that time-offset and it will break. Granted, it will break operating-system wide and we’ll probably have to manually set our system clocks, but the UTC offset that’s reported by the OS will be wrong for half the year too.

Why would the UTC offset be wrong for California? You could be on the Moon and get the right offset of your current time to UTC.

@Beatrix W Right now California is in the PST timezone, and the UTC Offset is calculated taking the time reported by the system clock and then applying the Daylight Saving Time rules for PST to the current time.

Once California implements always-on-DST, it no longer follows the rules of PST, and there is no locale with the proper rules in place for the user to switch their system to, as there is no other place in the world with always-on-DST. The current code to calculate UTC Offset will be off by 1 in the winter months without an operating system update to create the proper locale. El Capitan and Yosemite will likely not get these updates so the solution is not viable to me.

It’s a tricky problem for sure. Perhaps the only solution is to add a manual UTC offset override to the UI and let the user update it when necessary. Retrieving the actual UTC from a time server rather than calculating it based on locale rules would get around this as well but I can’t assume an always-on internet connection on a desktop app.

I don’t understand the problem. The computers in California will get their own locale. Even without the locale a computer has a current time. Doesn’t even matter which time. You can calculate the difference to UTC.

Additionally, there is a database for DST. If your computers don’t have access to the internet you could read this database.

@Beatrix Willius The computers will get their own locale except for those that are not getting updates. But those who don’t get updates that remain on the PST locale will get the incorrect UTC delta.

Consider that today a computer in California will get a UTC difference of -7.

But in November, assuming California has implemented always-on DST (still unknown when it will be implemented despite voter approval), a computer that has not been updated will fall back an hour.

The user may realize events are an hour late because of the time change that no longer occurs in California and will then manually change the system clock to compensate. But the locale rules of a computer that has not been updated will return a UTC difference of -8 when it still should be -7 and my application will still trigger events one hour late if I base the triggers on UTC time instead of local time.

I should mention that this application caters to the farming industry and interfaces with field hardware. Many of my users will not have internet access to update their OS, update the application, or contact a time server.

I greatly appreciate everyone’s thoughtful suggestions!

I too live in California… but was under the impression that while “we” voted to stop switching… the legislature had to decide WHICH side of the line to “keep”…do we stay with what we have today (we changed last night)… or do we go back to what it was a few days ago? Either way… my understanding was it would be a “few years” before all the consequences were hammered out, including needing to be approved by Congress.

@Dave S CBS Sacramento suggests that this may be it.

I have never known Congress to move that fast… so not holding my breath quite yet :slight_smile:

I guess I’m off the track. Anyway, using macOSlib I can know if a location supports DST and if at a given date/time DTS for such location is On or Off.
But as I said, I may be completely off the track.

Carlo… the issue is surrounding the fact that “soon” California will be opting out of DST (like parts of Arizona already do)… And that it will take some period of time for macOS/Windows etc to update the latest versions of their OS to deal with it… not to mention anyone that is NOT running the most up to date OS (including iOS) will get wrong time information for California after that transition.

So what macOSLib tells you now… could be wrong for some users in the future.

@ Dave S
Thank you Dave for making the issue clearer.

Europe will be doing the same thing. The problem here is that each state will be allowed to decide whether to keep Summer or Winter time! :smiley:

But UTC is Universal Time Code.
It is basically GMT. Always
No matter what the local decision is.

Even Britain doesnt stay on GMT ( at the moment).
So when we go to Daylight Savings, GMT and UTC are out by an hour.
If you always work in UTC, it ‘just works’

Unless you are saying that your app needs to do something and then react to whatever LOCAL time is, rather than elapsed time?

And what about the computer date is wrong (because its battery is off) ?

Also, in Europe (AFAIK), the changes will happens in the night of the last March Sunday (2:00 --> 3:00) and back in the last October’s Sunday (if my memory is correct).

Since some years, my computers change the DST by themselves (it was not always the case); my non smart telephone have to be changed manually.

This is the first time since DST appeared in France (1976) that I saw this question. (Yes, you now know that I do not understand what the trouble is/can be).

[quote=427819:@Jeff Tullin]But UTC is Universal Time Code.
It is basically GMT. Always
No matter what the local decision is.[/quote]
But your average person doesn’t use (or care) about GMT. they want to know what Time it is, where they are…

The point here is… those computers won’t KNOW anymore (unless they get an OS upgrade)