3 ms·

Dealing with time-zones and daylight savings time (which countries have it and which don't) can be a very challenge and messy problem that is really easy to get

Dealing with time-zones and daylight savings time (which countries have it and which don't) can be a very challenge and messy problem that is really easy to get wrong. Heres a pretty good video from computerphile on the subject https://www.youtube.com/watch?v=-5wpm-gesOY https://www.youtube.com/watch?v=-5wpm-gesOY

wangchow 10y ago
Spring forward, fall back!
- zaphar 10y ago
  But not every country or even every part of every country...
collyw 10y ago
Won't most mainstream languages have a built in library for that sort of thing these days?
- dcornu 10y ago
  They do. The problem is that the rules of DST change over time (sometimes at the very last minute https://github.com/eggert/tz/commit/868f3528a9fd60491439ce457f6d68dc12ef425b https://github.com/eggert/tz/commit/868f3528a9fd60491439ce45...) and can lead to all sorts of date math bugs when comparing timestamps across timezones.
- gregmac 10y ago
  Most do, but the problem is less about the library and more about understanding how to use it. For example, if you want an event to happen in 12 hours, and it happens to be 9pm the day before daylight savings time, do you schedule it using the timezone-aware API (so it happens at 9am, which is actually 13 hours away) or 8am (which is 12 hours, but non intuitive)? What about the event that's supposed to happen every 12 hours in perpetuity? What happens when the user/device is mobile, and crossing timezones? Which times do you use? What happens when you're scheduling something far in advance, and then the timezone definition itself changes (as happens a few times a year) between the time you scheduled the event, and the time something actually is supposed to happen? Does the event adjust for the new definition or follow original time? Luckily for many problem domains, the details around this don't matter too much, but this is just the tip of the iceberg with timezone challenges.
- douche 10y ago
  A lot of them are... not great. Moment.js makes it somewhat bearable in JS, but the native stuff is hot garbage.
- PeterisP 10y ago
  The libraries don't really help with some issues. E.g. a rather trivial example of displaying a hourly graph/table of some measurement, including comparison with yesterday (because there are daily patterns of fluctuation). DST means that some of days have 23 hours and some days have 25 hours. The libraries will help you make the relevant calculations, but now you have to make a decision wether the comparison that you make with "yesterday equivalent" of today's 11:00 is yesterday's 11:00 (23 hours ago) or yesterday's 10:00 (24 hours ago). For another example, accounting of hours worked - you may have a person that has worked 25 hours in a single day, such events break some systems.

wangchow 10y ago

Spring forward, fall back!

zaphar 10y ago
But not every country or even every part of every country...

collyw 10y ago

Won't most mainstream languages have a built in library for that sort of thing these days?

dcornu 10y ago
They do. The problem is that the rules of DST change over time (sometimes at the very last minute https://github.com/eggert/tz/commit/868f3528a9fd60491439ce457f6d68dc12ef425b https://github.com/eggert/tz/commit/868f3528a9fd60491439ce45...) and can lead to all sorts of date math bugs when comparing timestamps across timezones.
gregmac 10y ago
Most do, but the problem is less about the library and more about understanding how to use it. For example, if you want an event to happen in 12 hours, and it happens to be 9pm the day before daylight savings time, do you schedule it using the timezone-aware API (so it happens at 9am, which is actually 13 hours away) or 8am (which is 12 hours, but non intuitive)? What about the event that's supposed to happen every 12 hours in perpetuity? What happens when the user/device is mobile, and crossing timezones? Which times do you use? What happens when you're scheduling something far in advance, and then the timezone definition itself changes (as happens a few times a year) between the time you scheduled the event, and the time something actually is supposed to happen? Does the event adjust for the new definition or follow original time? Luckily for many problem domains, the details around this don't matter too much, but this is just the tip of the iceberg with timezone challenges.
douche 10y ago
A lot of them are... not great. Moment.js makes it somewhat bearable in JS, but the native stuff is hot garbage.
PeterisP 10y ago
The libraries don't really help with some issues. E.g. a rather trivial example of displaying a hourly graph/table of some measurement, including comparison with yesterday (because there are daily patterns of fluctuation). DST means that some of days have 23 hours and some days have 25 hours. The libraries will help you make the relevant calculations, but now you have to make a decision wether the comparison that you make with "yesterday equivalent" of today's 11:00 is yesterday's 11:00 (23 hours ago) or yesterday's 10:00 (24 hours ago). For another example, accounting of hours worked - you may have a person that has worked 25 hours in a single day, such events break some systems.