5 ms·

Samoa cancels Friday 30th and travels one day forward in time

77 points by tjriley82 15y ago

rmc 15y ago
It's cases like this that show that you should use a proper timezone library in your code. Too often I see websites where the timezone field is given as "+/- X from GMT". Just store everything in UTC, and use tzdata fields (e.g. "Europe/London") to convert to something nice to show the user, and People Cleverer Than You™ will make sure everything works.
- naz 15y ago
  Would timezone libraries handle this specific case? Genuinely curious, not being sarcastic.
  - jeltz 15y ago
    Yes they will, but this time they seems to have missed it so the updated database will be released after the change. See the thread about this in the Olson database mailing list. http://mm.icann.org/pipermail/tz/2011-December/008457.html http://mm.icann.org/pipermail/tz/2011-December/008457.html EDIT: Correction, that thread was about Tokelau and not Samoa. The Samoan change seems to already be in the latest version of the database.
- grimlck 15y ago
  Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on your server to a newer version, which incorporates the Somoa tz change. Now, without any user input, the appointment is suddenly on Jun 3, 2012! (because the same UTC date, with the updated TZ database, is Jun 3, 2012) Is that what a user would have expected if they created the appointment for Jun 2, 2012? I would say no. But that said, what if the appointment was for Dec 30 2011? That date no longer exists, so it would have be pushed ahead automatically. Conclusion: time zones are hard
  - natrius 15y ago
    My assumption was that the TZ database noted when changes in time zones happened so there was always an accurate one-to-one mapping between a Unix time and a time in each time zone. Adding 2012's time zone information wouldn't override 2010's. Is this incorrect?
    - elefont2 15y ago
      it does, but you cannot predict future legislation. In 2010, you may not yet know that the timezones will change in 2012, but you might still need to store a 2012 date in your database. So, the best you can do, if storing in UTC, is store that 2012 date using 2010 timezone rules, as you don't yet know what the 2012 time zone rules are going to be
    - rmc 15y ago
      > there was always an accurate one-to-one mapping between a Unix time and a time in each time zone That's not true in general. When the "clocks go backwards", there are two 1:30ams on that morning. The bug this comment is refering to, is where you convert from local to UTC as soon as the user enters the datetime, and then use that from then on. Since the "local to UTC" conversion might change between now and the date, as the tzdata time is updated, you might get this bug.
      - mikeash 15y ago
        It seems to me that it's impossible to solve this bug in the general case. If the user enters March 15, 2012 before the switch, should that become March 16, 2012 after the switch, or stay March 15? Either scenario could be correct depending on the intent of the date. Messy.
  - rmc 15y ago
    Yes, you're right. In cases like that you should store future events as local time, and wait until a resonable time before the event (e.g. a week) to convert from local to UTC. Then you will have (hopefully) an updated tzdata file.
- vl 15y ago
  While it's better than nothing, doesn't solve the problem of the future legislation. Real example from the corporate life (specific software in this case was Exchange/Outlook): meeting is scheduled between Seattle and Beijing locations, US changes start date of the date-light savings time. One of the meeting times needs to be updated, so people would still meet at the same time, but whatever time you update you move meeting by one hour at this location, creating conflicts and upsetting users. Even simpler problem is not so easy to handle in software: if you save dates in UTC, once DST start date changes, all your meetings move one hour, but most meetings are scheduled in "local" time, i.e. dentist still expectes to see you at 10am.
ars 15y ago
I'm quite curious if local churches will follow along with the change. I know Jews wouldn't, and I doubt Muslims would, but I don't think there are any Jews there anyway, not sure about Muslims.
- jonknee 15y ago
  Why not? It's arbitrary anyways--as the article mentions the same place previously switched (which means if the Jews didn't like change they would still be on the time that everyone is now switching back to).
  - ars 15y ago
    The Jewish religion has it's own date line that does not correspond to the international one. My question was what does Christianity do, and I guess no one here knows.
    - protomyth 15y ago
      Christianity is actually split on which day to keep. Those that follow the Catholic Church (via canon 29 of the Council of Laodicea) worship on Lord's Day[1] (Sunday). Those that feel the church could not change the day of worship (e.g. Seventh Day Baptists) worship on the Sabbath (Saturday). Wikipedia has a small breakdown for the 7th day in http://en.wikipedia.org/wiki/Sabbath http://en.wikipedia.org/wiki/Sabbath - some going with local, some going with time in Israel. Not being Jewish, I am not sure how accurate this one is for Jews: http://www.star-k.org/kashrus/kk-trav-dateline.htm http://www.star-k.org/kashrus/kk-trav-dateline.htm It was my understanding that Catholics go with local to determine Sunday. [1] http://en.wikipedia.org/wiki/Lord%27s_Day http://en.wikipedia.org/wiki/Lord%27s_Day
    - noonespecial 15y ago
      I'd say that except for a few groups(1), Christians just want a day and aren't too concerned about which day. (1) http://en.wikipedia.org/wiki/Seventh-day_Adventist_Church http://en.wikipedia.org/wiki/Seventh-day_Adventist_Church
- 15y ago
Pelayo 15y ago
And they become the first to celebrate the new year on the last new year there will ever be.
qntm 15y ago
It's actually quite lucky that the world has a sensible longitude upon which an International Date Line can be dropped. Imagine if there was an unbroken ring of industrialised nations going all the way around the Earth, I can see a situation where each nation wants to do business with the nation to its immediate west so badly that they just adjust their clocks forward and forward over the course of decades. Eventually, every nation on Earth has done it, and an entire day has essentially disappeared from the calendar - except that the UK is at UTC+24:00 now.
- dkasper 15y ago
  Perhaps we would have a different notation of time if this were the case.
jorisw 15y ago
I would not want to be a calendar software developer right now.
- jonknee 15y ago
  Why not? It's a simple timezone change. Moreover, it's a timezone change that effects a very small number of people.
- rmc 15y ago
  It's easy, just use tzdata (you are using tzdata, right) and it'll take care of most of the transformations.
tlholaday 15y ago
I was pleased that the author, Seth Mydans described January 1, 2000 as "what was called the new millennium."
finnw 15y ago
Another version of the story for non-NYT subscribers: http://www.bbc.co.uk/news/world-asia-16351377 http://www.bbc.co.uk/news/world-asia-16351377
redthrowaway 15y ago
Who decided to cancel Friday? Surely there would have been greater agreement for cancelling Monday.
- marquis 15y ago
  Then tuesday is the new monday.. you can't escape it. Also, easier to cope with changes over the weekend for those doing international business.
languagehacker 15y ago
Samoa will do anything to make it easier to trade with Australia, including switching what side of the road drivers should use. It's getting a little ridiculous.
- marquis 15y ago
  Samoans mostly live and work in/with Australia and New Zealand. Doesn't that make more sense, than pretending they are closer to the U.S.?
malvim 15y ago
Here's hoping no samoans have their birthdays on December 30th. It would sure suck if my government cancelled the entire day of my birthday!
AngryParsley 15y ago
The change in timezone data exposed a bug in pytz: https://bugs.launchpad.net/pytz/+bug/885163 https://bugs.launchpad.net/pytz/+bug/885163
technomancy 15y ago
I love it when the news prompts flashbacks to Umberto Eco. http://en.m.wikipedia.org/wiki/The_Island_of_the_Day_Before http://en.m.wikipedia.org/wiki/The_Island_of_the_Day_Before

77 points by tjriley82 15y ago

rmc 15y ago

It's cases like this that show that you should use a proper timezone library in your code. Too often I see websites where the timezone field is given as "+/- X from GMT". Just store everything in UTC, and use tzdata fields (e.g. "Europe/London") to convert to something nice to show the user, and People Cleverer Than You™ will make sure everything works.

naz 15y ago
Would timezone libraries handle this specific case? Genuinely curious, not being sarcastic.
- jeltz 15y ago
  Yes they will, but this time they seems to have missed it so the updated database will be released after the change. See the thread about this in the Olson database mailing list. http://mm.icann.org/pipermail/tz/2011-December/008457.html http://mm.icann.org/pipermail/tz/2011-December/008457.html EDIT: Correction, that thread was about Tokelau and not Samoa. The Samoan change seems to already be in the latest version of the database.
grimlck 15y ago
Storing everything in UTC is a huge improvement, but is still an imperfect solution because the Tz database changes over time. Suppose you are writing a appointment tracking system, and, at some point before the olson tz database has been updated with this change, the user in the Samoa timezone creates an future appointment for Jun 2, 2012. That would be stored in UTC. Now, you upgrade the olson TZ database file on your server to a newer version, which incorporates the Somoa tz change. Now, without any user input, the appointment is suddenly on Jun 3, 2012! (because the same UTC date, with the updated TZ database, is Jun 3, 2012) Is that what a user would have expected if they created the appointment for Jun 2, 2012? I would say no. But that said, what if the appointment was for Dec 30 2011? That date no longer exists, so it would have be pushed ahead automatically. Conclusion: time zones are hard
- natrius 15y ago
  My assumption was that the TZ database noted when changes in time zones happened so there was always an accurate one-to-one mapping between a Unix time and a time in each time zone. Adding 2012's time zone information wouldn't override 2010's. Is this incorrect?
  - elefont2 15y ago
    it does, but you cannot predict future legislation. In 2010, you may not yet know that the timezones will change in 2012, but you might still need to store a 2012 date in your database. So, the best you can do, if storing in UTC, is store that 2012 date using 2010 timezone rules, as you don't yet know what the 2012 time zone rules are going to be
  - rmc 15y ago
    > there was always an accurate one-to-one mapping between a Unix time and a time in each time zone That's not true in general. When the "clocks go backwards", there are two 1:30ams on that morning. The bug this comment is refering to, is where you convert from local to UTC as soon as the user enters the datetime, and then use that from then on. Since the "local to UTC" conversion might change between now and the date, as the tzdata time is updated, you might get this bug.
    - mikeash 15y ago
      It seems to me that it's impossible to solve this bug in the general case. If the user enters March 15, 2012 before the switch, should that become March 16, 2012 after the switch, or stay March 15? Either scenario could be correct depending on the intent of the date. Messy.
- rmc 15y ago
  Yes, you're right. In cases like that you should store future events as local time, and wait until a resonable time before the event (e.g. a week) to convert from local to UTC. Then you will have (hopefully) an updated tzdata file.
vl 15y ago
While it's better than nothing, doesn't solve the problem of the future legislation. Real example from the corporate life (specific software in this case was Exchange/Outlook): meeting is scheduled between Seattle and Beijing locations, US changes start date of the date-light savings time. One of the meeting times needs to be updated, so people would still meet at the same time, but whatever time you update you move meeting by one hour at this location, creating conflicts and upsetting users. Even simpler problem is not so easy to handle in software: if you save dates in UTC, once DST start date changes, all your meetings move one hour, but most meetings are scheduled in "local" time, i.e. dentist still expectes to see you at 10am.

ars 15y ago

I'm quite curious if local churches will follow along with the change. I know Jews wouldn't, and I doubt Muslims would, but I don't think there are any Jews there anyway, not sure about Muslims.

jonknee 15y ago
Why not? It's arbitrary anyways--as the article mentions the same place previously switched (which means if the Jews didn't like change they would still be on the time that everyone is now switching back to).
- ars 15y ago
  The Jewish religion has it's own date line that does not correspond to the international one. My question was what does Christianity do, and I guess no one here knows.
  - protomyth 15y ago
    Christianity is actually split on which day to keep. Those that follow the Catholic Church (via canon 29 of the Council of Laodicea) worship on Lord's Day[1] (Sunday). Those that feel the church could not change the day of worship (e.g. Seventh Day Baptists) worship on the Sabbath (Saturday). Wikipedia has a small breakdown for the 7th day in http://en.wikipedia.org/wiki/Sabbath http://en.wikipedia.org/wiki/Sabbath - some going with local, some going with time in Israel. Not being Jewish, I am not sure how accurate this one is for Jews: http://www.star-k.org/kashrus/kk-trav-dateline.htm http://www.star-k.org/kashrus/kk-trav-dateline.htm It was my understanding that Catholics go with local to determine Sunday. [1] http://en.wikipedia.org/wiki/Lord%27s_Day http://en.wikipedia.org/wiki/Lord%27s_Day
  - noonespecial 15y ago
    I'd say that except for a few groups(1), Christians just want a day and aren't too concerned about which day. (1) http://en.wikipedia.org/wiki/Seventh-day_Adventist_Church http://en.wikipedia.org/wiki/Seventh-day_Adventist_Church
15y ago

Pelayo 15y ago

And they become the first to celebrate the new year on the last new year there will ever be.

qntm 15y ago

It's actually quite lucky that the world has a sensible longitude upon which an International Date Line can be dropped. Imagine if there was an unbroken ring of industrialised nations going all the way around the Earth, I can see a situation where each nation wants to do business with the nation to its immediate west so badly that they just adjust their clocks forward and forward over the course of decades. Eventually, every nation on Earth has done it, and an entire day has essentially disappeared from the calendar - except that the UK is at UTC+24:00 now.

dkasper 15y ago
Perhaps we would have a different notation of time if this were the case.

jorisw 15y ago

I would not want to be a calendar software developer right now.

jonknee 15y ago
Why not? It's a simple timezone change. Moreover, it's a timezone change that effects a very small number of people.
rmc 15y ago
It's easy, just use tzdata (you are using tzdata, right) and it'll take care of most of the transformations.

tlholaday 15y ago

I was pleased that the author, Seth Mydans described January 1, 2000 as "what was called the new millennium."

finnw 15y ago

Another version of the story for non-NYT subscribers: http://www.bbc.co.uk/news/world-asia-16351377 http://www.bbc.co.uk/news/world-asia-16351377

redthrowaway 15y ago

Who decided to cancel Friday? Surely there would have been greater agreement for cancelling Monday.

marquis 15y ago
Then tuesday is the new monday.. you can't escape it. Also, easier to cope with changes over the weekend for those doing international business.

languagehacker 15y ago

Samoa will do anything to make it easier to trade with Australia, including switching what side of the road drivers should use. It's getting a little ridiculous.

marquis 15y ago
Samoans mostly live and work in/with Australia and New Zealand. Doesn't that make more sense, than pretending they are closer to the U.S.?

malvim 15y ago

Here's hoping no samoans have their birthdays on December 30th. It would sure suck if my government cancelled the entire day of my birthday!

AngryParsley 15y ago

The change in timezone data exposed a bug in pytz: https://bugs.launchpad.net/pytz/+bug/885163 https://bugs.launchpad.net/pytz/+bug/885163

technomancy 15y ago

I love it when the news prompts flashbacks to Umberto Eco. http://en.m.wikipedia.org/wiki/The_Island_of_the_Day_Before http://en.m.wikipedia.org/wiki/The_Island_of_the_Day_Before