7 ms·

Timezone updates need to be fixed

27 points by laut 11y ago

laut 11y ago
2016a has been released: https://www.iana.org/time-zones https://www.iana.org/time-zones If you use the Elixir library mentioned in the article, it will already have been updated. If you use Mac OS X Yosemite it will probably never be updated.
sbierwagen 11y ago
But the data itself is not new software. It is just data. Functionality should not change because of new data. Well, ideally, yes. But software breaks all the time when you give it data the programmer didn't expect, which happens especially often with time. DST, for example. What if a state stops observing DST? Arizona observed DST in 1967, but hasn't since then. A couple other states are considering abolishing it, too. You can easily imagine software doing something dumb when it can't find its DST entry in tzdata.
- laut 11y ago
  I don't think it is a good idea to shield bad software at the expensive of having incorrect out-of-date data. Developers should be aware that tzdata changes all the time, and create software that can deal with it.
petke 11y ago
I got programs connecting to servers in different countries. It was such a pain to keep the time in sync with all the different time zones and daylight savings. So i ended up using utc everywhere. i even set the clock on the wall and my wrist watch to utc. That way I'm also in sync with my programs. People who visit tell me my clocks are wrong. But i know its the the rest of the world that is wrong.
- sbierwagen 11y ago
  Use unix time and NTP.
  - petke 11y ago
    Yes. Unix time is utc based. I used manual syncing to ntp server once in a while. Automatic syncing scares me a bit. What happens when it adjust backwards in time. Programs that are running and use elapsed time logic might get very confused. Elapsed time since an event happened might become negative.
    - HeXetic 11y ago
      > What happens when it adjust backwards in time. NTP deliberately makes only very tiny changes gradually when adjusting clock time backwards. Automatic updates also normally abort if the time difference would be more than 1000s (~16m). This is all fairly well-documented. https://www.eecis.udel.edu/~mills/ntp/html/index.html https://www.eecis.udel.edu/~mills/ntp/html/index.html
      - petke 11y ago
        Interesting. Still any backward adjustment however small seems potentially dangerous. I googled a bit and it seems many ntp services can slow down the time until its in sync instead of adjusting it backwards. That seems safer.
        gwright 11y ago
        Generally it isn't a backward adjustment but simply a slowing down of the clock until the 'real time' catches up. On the other side, you speed up a clock to catch up to the real time rather than catching up all at once.
ape4 11y ago
How about a way to encode future timezone changes? If a country votes for a timezone change it doesn't become law tomorrow. Usually they schedule it for a date in a few months. If a week after the vote tzdata knew this then there would be no rush.
- smackfu 11y ago
  Here's an example from Argentina in 2007: http://blogs.technet.com/b/dst2007/archive/2007/12/29/argentina-122907.aspx http://blogs.technet.com/b/dst2007/archive/2007/12/29/argent... Less than a week's notice of the change, and it was between Christmas and New Year. Ouch.
  - ape4 11y ago
    They deserved all the wrong times they probably got.
- toast0 11y ago
  Tzdata can encode future changes, but that's only helpful when politicians change the rules on advance and notice is given to the team that manages the data. Many jurisdictions don't appear to consider the impacts of changes and make changes with little notice.
phicoh 11y ago
Looking at this from a 'Unix in Europe' perspective, the timezone data has rules. So as long as the rules don't change you don't need updates. And due to the need to coordinate with many countries, timezone rules in the EU essentially don't change. It seems that in some countries, time zones just change randomly. Maybe people should just stop doing that. Countries only move a couple of centuries a year. And there is no reason to mess with DST other than to get rid of it all together.
- maw 11y ago
  Maybe people should just stop doing that. I don't disagree, but how do we get there from here? Our "betters" have even had the gall to make this type of change in the recent past, and even to claim "energy efficiency" as a motivation. This is is--how do I put this?--a wronger than wrong version of not even wrong.
  - phicoh 11y ago
    One option is to get one of those big name companies to write a report on how much that change cost to the economy due equipment that had to be written off, downtime, etc. Doesn't have to accurate, just impressive. And then maybe next time, circulate the report just before the decision has to be taken.
- greggyb 11y ago
  I can't help it... > Countries only move a couple of centuries a year. That's some pretty advanced time travel tech.
  - phicoh 11y ago
    Wow, how did that happen? I meant to write centimeters.
gregmac 11y ago
One of the biggest problems with tzdata is only mentioned in passing in the article: > If you make a system that uses timezone data, think ahead. The timezone data is updated as often as 10 times a year or more. In case you have an embedded system that is not connected to the internet all the time, how can that processes be put in place to make sure it is updated? A decade or so ago, nothing updated, and when DST changed, you had to reset every clock in the house. There was maybe a day or two of confusion where you couldn't remember if you changed a clock or not, but easily dealt with. Now, in my house anyway, almost everything automatically switches (with the notable exception of my stove and microwave clocks, but heck, those still don't even have battery backup for when the power flickers). This is probably even more annoying, because now it's not a matter of remembering if I switched it (in the last day or so) or not, it's remembering if the device itself switches automatically or not. I can't remember stuff like that, so basically for a day or two after DST I don't trust any clocks at all. Worse is when the devices still have the old (pre-2007) DST rules built-in. We're lucky in NA that the rules don't change that much, but when they do, they do break all these old devices. The most annoying item I had (notice past tense) was a beside clock that auto-set itself I believe based on the WWV [1] signal, and had a setting for time-zone and would of course do DST shifts automatically. Pretty neat, when I first got it, but after 2007, I had to manually change the timezone on this "auto-setting clock" 4 times a year. [1] https://en.wikipedia.org/wiki/WWV_(radio_station) https://en.wikipedia.org/wiki/WWV_(radio_station)
- teraflop 11y ago
  > Pretty neat, when I first got it, but after 2007, I had to manually change the timezone on this "auto-setting clock" 4 times a year. That's odd, because the WWV signal contains extra flag bits that authoritatively tell you when DST is starting and ending. I guess the manufacturers decided to ignore that data and reimplement the time change themselves. https://en.wikipedia.org/wiki/WWV_(radio_station)#Daylight_saving_time_and_leap_seconds https://en.wikipedia.org/wiki/WWV_(radio_station)#Daylight_s...
  - gregmac 11y ago
    Wow, that actually makes me very frustrated, because it means not only did they ignore that flag (not read the documentation?), they actually did more work to implement a tzdata database and check against the current date to change it. Of course, IIRC it also only had 4 timezone settings, so I guess if you lived in Hawaii, Alaska, the Atlantic time zone, or Newfoundland, you were out of luck. And if you lived in Arizona or Saskatchewan or any other place that didn't observe DST, you were also out of luck. (Well, you could at least manually adjust the time, which I think turned off the auto-DST stuff).
TheBranca18 11y ago
As someone who just spent some time figuring out why Australians were getting errors on the site I work for, I fully support standardizing automatic updates. Since the site is running a two year old version of PHP, it looks like I either have to update the PHP version to the latest (just to be safe) or add the timezonedb PECL package. This seems to be a ton of work just to get something that should be updated automatically.
Khao 11y ago
Where I work we deal a lot with events (yoga gyms, community sports centers, etc.) and the old code was saving EVERYTHING in UTC. Every 6 months we'd have some bug report coming in saying that some event was now one hour later or earlier on the website, or in some report, or in an admin edit screen. I got fed up with this and migrated all the data so it's saved in local time with the timezone information in a separate column. If an admin creates an event for 4pm, we save 4pm with the event location's timezone. Since an event only takes place at one specific location, it makes no sense to have the data in UTC in the database. We can convert to UTC if we want but it's not really useful. The thinking is that if a client is shopping for a class in a different timezone, why would we convert the class's time to the client's timezone? It makes no sense. It's always in local time. This has helped so much.
- laut 11y ago
  Yup. I wrote about this here: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...
  - Avernar 11y ago
    Nice article. For your rule of thumb section there is a third case. For a future event that must happen x number of seconds/minutes/hours/days into the future you want to store it as UTC and not wall time. For example, the bypass valve on the boiler must be opened in 30 hours. You want that as UTC instead of wall time as you don't want a DST change to add an extra hour to that as you'd get a pile of scrap instead of an intact boiler.
    - laut 11y ago
      Good point. For that that situation you would want to use something like UTC (or TAI). It is the duration from the starting point that we care about, not the future date.
- vemv 11y ago
  Seems a misguided practice to me. * Store datetime values in UTC. Else you get inconsistent values, which has unpredictable consequences. * Detect user's expected timezone using one of : a) user preference setting, b) the region the app is supposed to be running for, c) IP geolocation. Choice depends on the app requirements. Don't default to any timezone unless considered 100% safe. * Present DB values in the UI using said detected timezone. * UI-wise, slways display timezone information for datetime values. At the very least in a tooltip.
kijeda 11y ago
The IETF has been working on distribution issues and, amongst other documents from the tzdist working group, produced this: https://datatracker.ietf.org/doc/draft-ietf-tzdist-service https://datatracker.ietf.org/doc/draft-ietf-tzdist-service
Happpy 11y ago
All use utc and stop the daylight saving and timezone... Use gps coord. And utc to know if you have a lunch or breakfast, dinner meeting Time zones have no precision so why use them?
- BurningFrog 11y ago
  I agree, but to do that you need root to the World. As long as we're regular users, we need to work around these realities.
Grue3 11y ago
My HTC One still uses years old timezone information for its clock widget. I fixed the main clock by setting timezone to a different timezone that I'm actually in, but the clock widget is still off by one hour. It's extremely infuriating. Apparently you can't update timezone information in Android unless you have root, which is completely idiotic.
vemv 11y ago
Are up-to-date Rails applications exposed to this issue? Not 100% sure, but from what I know, Rails gets timezone handling right. Specifically, it leverages the https://github.com/tzinfo/tzinfo https://github.com/tzinfo/tzinfo gem. So, correct me if I wrong, by performing `bundle update` you're all good?
- laut 11y ago
  AFAIK you can use the tzinfo-data gem. Someone needs to manually update it though. So far it looks like it is still on the previous 2015g and not on 2016a that just got released: https://github.com/tzinfo/tzinfo-data https://github.com/tzinfo/tzinfo-data
SFjulie1 11y ago
Timezone problems (cf The Problem with Time & Timezones - Computerphile on youtube or postgres doc on why not to use TZ) are not solvable. TZ are politics and politic is very bad at making stuff engineerable. Politics are inconsistent, unstable and lack of rigor in propagating the information to the coders. The TZ definitions are handled by clerks that writes an XML files manually that are embedded in your libs and that no one cares to update. TZ are not versioned. So if you want to know what was the local time 12years ago in any place of the world : good luck. But international exchange are bound to delays workhours and SLA requiring delays to be measurable ... With arbitrary changes (EST shit). Timezones are broken by design and all our applications too. The only way to solve the problem is to forbid politics to come anywhere near science, history and standardization of measurement. Corporation don't do any better. I abide by International System (metric) and the idea that there should be a monotonic non disrupted absolute time whose origin IS NOT the birth of Christ but since when we are able to have continuous "rigorous" measurement of time. Which is exactly the opposite of what people calls for. The begining of the year should be the aphelia (3~4 jan) and not some religious bat shit conventions. Noon should be when the sun is at its top. And 13 month of 28 days (+intercalar days) would make our lives easier. Time as a political and religious construct is shit.

27 points by laut 11y ago

laut 11y ago

2016a has been released: https://www.iana.org/time-zones https://www.iana.org/time-zones If you use the Elixir library mentioned in the article, it will already have been updated. If you use Mac OS X Yosemite it will probably never be updated.

sbierwagen 11y ago

But the data itself is not new software. It is just data. Functionality should not change because of new data. Well, ideally, yes. But software breaks all the time when you give it data the programmer didn't expect, which happens especially often with time. DST, for example. What if a state stops observing DST? Arizona observed DST in 1967, but hasn't since then. A couple other states are considering abolishing it, too. You can easily imagine software doing something dumb when it can't find its DST entry in tzdata.

laut 11y ago
I don't think it is a good idea to shield bad software at the expensive of having incorrect out-of-date data. Developers should be aware that tzdata changes all the time, and create software that can deal with it.

petke 11y ago

I got programs connecting to servers in different countries. It was such a pain to keep the time in sync with all the different time zones and daylight savings. So i ended up using utc everywhere. i even set the clock on the wall and my wrist watch to utc. That way I'm also in sync with my programs. People who visit tell me my clocks are wrong. But i know its the the rest of the world that is wrong.

sbierwagen 11y ago
Use unix time and NTP.
- petke 11y ago
  Yes. Unix time is utc based. I used manual syncing to ntp server once in a while. Automatic syncing scares me a bit. What happens when it adjust backwards in time. Programs that are running and use elapsed time logic might get very confused. Elapsed time since an event happened might become negative.
  - HeXetic 11y ago
    > What happens when it adjust backwards in time. NTP deliberately makes only very tiny changes gradually when adjusting clock time backwards. Automatic updates also normally abort if the time difference would be more than 1000s (~16m). This is all fairly well-documented. https://www.eecis.udel.edu/~mills/ntp/html/index.html https://www.eecis.udel.edu/~mills/ntp/html/index.html
    - petke 11y ago
      Interesting. Still any backward adjustment however small seems potentially dangerous. I googled a bit and it seems many ntp services can slow down the time until its in sync instead of adjusting it backwards. That seems safer.
      - gwright 11y ago
        Generally it isn't a backward adjustment but simply a slowing down of the clock until the 'real time' catches up. On the other side, you speed up a clock to catch up to the real time rather than catching up all at once.

ape4 11y ago

How about a way to encode future timezone changes? If a country votes for a timezone change it doesn't become law tomorrow. Usually they schedule it for a date in a few months. If a week after the vote tzdata knew this then there would be no rush.

smackfu 11y ago
Here's an example from Argentina in 2007: http://blogs.technet.com/b/dst2007/archive/2007/12/29/argentina-122907.aspx http://blogs.technet.com/b/dst2007/archive/2007/12/29/argent... Less than a week's notice of the change, and it was between Christmas and New Year. Ouch.
- ape4 11y ago
  They deserved all the wrong times they probably got.
toast0 11y ago
Tzdata can encode future changes, but that's only helpful when politicians change the rules on advance and notice is given to the team that manages the data. Many jurisdictions don't appear to consider the impacts of changes and make changes with little notice.

phicoh 11y ago

Looking at this from a 'Unix in Europe' perspective, the timezone data has rules. So as long as the rules don't change you don't need updates. And due to the need to coordinate with many countries, timezone rules in the EU essentially don't change. It seems that in some countries, time zones just change randomly. Maybe people should just stop doing that. Countries only move a couple of centuries a year. And there is no reason to mess with DST other than to get rid of it all together.

maw 11y ago
Maybe people should just stop doing that. I don't disagree, but how do we get there from here? Our "betters" have even had the gall to make this type of change in the recent past, and even to claim "energy efficiency" as a motivation. This is is--how do I put this?--a wronger than wrong version of not even wrong.
- phicoh 11y ago
  One option is to get one of those big name companies to write a report on how much that change cost to the economy due equipment that had to be written off, downtime, etc. Doesn't have to accurate, just impressive. And then maybe next time, circulate the report just before the decision has to be taken.
greggyb 11y ago
I can't help it... > Countries only move a couple of centuries a year. That's some pretty advanced time travel tech.
- phicoh 11y ago
  Wow, how did that happen? I meant to write centimeters.

gregmac 11y ago

One of the biggest problems with tzdata is only mentioned in passing in the article: > If you make a system that uses timezone data, think ahead. The timezone data is updated as often as 10 times a year or more. In case you have an embedded system that is not connected to the internet all the time, how can that processes be put in place to make sure it is updated? A decade or so ago, nothing updated, and when DST changed, you had to reset every clock in the house. There was maybe a day or two of confusion where you couldn't remember if you changed a clock or not, but easily dealt with. Now, in my house anyway, almost everything automatically switches (with the notable exception of my stove and microwave clocks, but heck, those still don't even have battery backup for when the power flickers). This is probably even more annoying, because now it's not a matter of remembering if I switched it (in the last day or so) or not, it's remembering if the device itself switches automatically or not. I can't remember stuff like that, so basically for a day or two after DST I don't trust any clocks at all. Worse is when the devices still have the old (pre-2007) DST rules built-in. We're lucky in NA that the rules don't change that much, but when they do, they do break all these old devices. The most annoying item I had (notice past tense) was a beside clock that auto-set itself I believe based on the WWV [1] signal, and had a setting for time-zone and would of course do DST shifts automatically. Pretty neat, when I first got it, but after 2007, I had to manually change the timezone on this "auto-setting clock" 4 times a year. [1] https://en.wikipedia.org/wiki/WWV_(radio_station) https://en.wikipedia.org/wiki/WWV_(radio_station)

teraflop 11y ago
> Pretty neat, when I first got it, but after 2007, I had to manually change the timezone on this "auto-setting clock" 4 times a year. That's odd, because the WWV signal contains extra flag bits that authoritatively tell you when DST is starting and ending. I guess the manufacturers decided to ignore that data and reimplement the time change themselves. https://en.wikipedia.org/wiki/WWV_(radio_station)#Daylight_saving_time_and_leap_seconds https://en.wikipedia.org/wiki/WWV_(radio_station)#Daylight_s...
- gregmac 11y ago
  Wow, that actually makes me very frustrated, because it means not only did they ignore that flag (not read the documentation?), they actually did more work to implement a tzdata database and check against the current date to change it. Of course, IIRC it also only had 4 timezone settings, so I guess if you lived in Hawaii, Alaska, the Atlantic time zone, or Newfoundland, you were out of luck. And if you lived in Arizona or Saskatchewan or any other place that didn't observe DST, you were also out of luck. (Well, you could at least manually adjust the time, which I think turned off the auto-DST stuff).

TheBranca18 11y ago

As someone who just spent some time figuring out why Australians were getting errors on the site I work for, I fully support standardizing automatic updates. Since the site is running a two year old version of PHP, it looks like I either have to update the PHP version to the latest (just to be safe) or add the timezonedb PECL package. This seems to be a ton of work just to get something that should be updated automatically.

Khao 11y ago

Where I work we deal a lot with events (yoga gyms, community sports centers, etc.) and the old code was saving EVERYTHING in UTC. Every 6 months we'd have some bug report coming in saying that some event was now one hour later or earlier on the website, or in some report, or in an admin edit screen. I got fed up with this and migrated all the data so it's saved in local time with the timezone information in a separate column. If an admin creates an event for 4pm, we save 4pm with the event location's timezone. Since an event only takes place at one specific location, it makes no sense to have the data in UTC in the database. We can convert to UTC if we want but it's not really useful. The thinking is that if a client is shopping for a class in a different timezone, why would we convert the class's time to the client's timezone? It makes no sense. It's always in local time. This has helped so much.

laut 11y ago
Yup. I wrote about this here: http://www.creativedeletion.com/2015/03/19/persisting_future_datetimes.html http://www.creativedeletion.com/2015/03/19/persisting_future...
- Avernar 11y ago
  Nice article. For your rule of thumb section there is a third case. For a future event that must happen x number of seconds/minutes/hours/days into the future you want to store it as UTC and not wall time. For example, the bypass valve on the boiler must be opened in 30 hours. You want that as UTC instead of wall time as you don't want a DST change to add an extra hour to that as you'd get a pile of scrap instead of an intact boiler.
  - laut 11y ago
    Good point. For that that situation you would want to use something like UTC (or TAI). It is the duration from the starting point that we care about, not the future date.
vemv 11y ago
Seems a misguided practice to me. * Store datetime values in UTC. Else you get inconsistent values, which has unpredictable consequences. * Detect user's expected timezone using one of : a) user preference setting, b) the region the app is supposed to be running for, c) IP geolocation. Choice depends on the app requirements. Don't default to any timezone unless considered 100% safe. * Present DB values in the UI using said detected timezone. * UI-wise, slways display timezone information for datetime values. At the very least in a tooltip.

kijeda 11y ago

The IETF has been working on distribution issues and, amongst other documents from the tzdist working group, produced this: https://datatracker.ietf.org/doc/draft-ietf-tzdist-service https://datatracker.ietf.org/doc/draft-ietf-tzdist-service

Happpy 11y ago

All use utc and stop the daylight saving and timezone... Use gps coord. And utc to know if you have a lunch or breakfast, dinner meeting Time zones have no precision so why use them?

BurningFrog 11y ago
I agree, but to do that you need root to the World. As long as we're regular users, we need to work around these realities.

Grue3 11y ago

My HTC One still uses years old timezone information for its clock widget. I fixed the main clock by setting timezone to a different timezone that I'm actually in, but the clock widget is still off by one hour. It's extremely infuriating. Apparently you can't update timezone information in Android unless you have root, which is completely idiotic.

vemv 11y ago

Are up-to-date Rails applications exposed to this issue? Not 100% sure, but from what I know, Rails gets timezone handling right. Specifically, it leverages the https://github.com/tzinfo/tzinfo https://github.com/tzinfo/tzinfo gem. So, correct me if I wrong, by performing `bundle update` you're all good?

laut 11y ago
AFAIK you can use the tzinfo-data gem. Someone needs to manually update it though. So far it looks like it is still on the previous 2015g and not on 2016a that just got released: https://github.com/tzinfo/tzinfo-data https://github.com/tzinfo/tzinfo-data

SFjulie1 11y ago

Timezone problems (cf The Problem with Time & Timezones - Computerphile on youtube or postgres doc on why not to use TZ) are not solvable. TZ are politics and politic is very bad at making stuff engineerable. Politics are inconsistent, unstable and lack of rigor in propagating the information to the coders. The TZ definitions are handled by clerks that writes an XML files manually that are embedded in your libs and that no one cares to update. TZ are not versioned. So if you want to know what was the local time 12years ago in any place of the world : good luck. But international exchange are bound to delays workhours and SLA requiring delays to be measurable ... With arbitrary changes (EST shit). Timezones are broken by design and all our applications too. The only way to solve the problem is to forbid politics to come anywhere near science, history and standardization of measurement. Corporation don't do any better. I abide by International System (metric) and the idea that there should be a monotonic non disrupted absolute time whose origin IS NOT the birth of Christ but since when we are able to have continuous "rigorous" measurement of time. Which is exactly the opposite of what people calls for. The begining of the year should be the aphelia (3~4 jan) and not some religious bat shit conventions. Noon should be when the sun is at its top. And 13 month of 28 days (+intercalar days) would make our lives easier. Time as a political and religious construct is shit.