2

So the EU is thinking about scrapping the DST and leave the decision to local government to decide to stay on winter time or summer time.

What does this means for existing code libraries and applications that deal with scheduling, timezone conversion etc?

Example,

Suppose currently depends on DST, my country time can be +8 UTC (summer) or +7 UTC (winter). After the EU change, my country time permanently +8 UTC.

If I have a schedule to send me an email everyday at 9:00:00 am (local time), I might save 9am in the database, then check

if(Date.utcNow().format(H:i:s, MY_TIMEZONE) == 09:00:00) sendEmail();

Will this code still work regardless of summer or winter after the EU change?

Alternatively, if I store in UTC 1:00:00 am (+0), then

if(Date.utcNow().format(H:i:s, UTC) == 01:00:00) sendEmail(); // actually this will NOT send at the same local time everyday, because I expect it to send at summer or winter time depending on DST.

Will this code automatically send at the new local time summer permanently after the EU change?

I assume someone will fix the time servers, but on my part do I need to update any code libraries and application logic?

DisappointedByUnaccountableMod
  • 6,656
  • 4
  • 18
  • 22
Jake
  • 11,273
  • 21
  • 90
  • 147

1 Answers1

2

It may not be as dire as you fear.

There exists something called the IANA time zone database. And as it turns out, a lot of languages and libraries already use this database to tell them about things like UTC offsets and time zone rules.

And the IANA time zone database itself is not static. It gets updated surprisingly often. And when it does, those platforms, languages and libraries that depend on it will typically update to the newer version as well. So higher level software just continues to work as time zone changes happen.

In the year 2018, the IANA time zone database was updated 9 times. That's about every 6 weeks on average. So changes in daylight saving rules are neither rare (on a global scale) or catastrophic.

Though the worst thing that can happen (and does with disturbing frequency) is for some brain-dead government to give less than a week's notice of changing daylight saving rules. Then, for that part of the world, there is confusion about the current time until all systems have had enough time to update.

In the EU's case, it appears that things are being thought through and planned out well in advance. So the IANA time zone database and all of the systems that depend on it will be able to update in plenty of time.

If you are aware of code that programs its own daylight saving rule logic, instead of depending on a well-maintained, updatable database of ever-changing time zone rules, then the prudent thing to do would be to migrate your code off of that custom logic asap.

As for the part of your question about how to store times for regularly scheduled events, best practice is to store the time stamp exactly as humans intend it. For example if you expect something to happen at 9am local time, then it should be programed for 9am local time. If you expect something to happen at the same instant globally, it should probably be programmed against UTC.

For more advice on best practices in this area, see this SO answer.

Update

Matt Johnson reminds us of the great article he wrote a few years ago which contains good advice for brain-dead governments. If they ever learn how to read, this is the first thing they should read: https://codeofmatt.com/on-the-timing-of-time-zone-changes/

Howard Hinnant
  • 206,506
  • 52
  • 449
  • 577