Samoa cancels Friday 30th and travels one day forward in time
nytimes.com
nytimes.com
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.
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
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
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.
Events in the future are commonly scheduled relative to what the time is going to be in a specific place, regardless of how the tz rules change in the meantime. Automated actions in the future, however, may well need to be fixed to a UTC time. In short: you need to think about how your system will actually be used, and possibly store values differently depending on how they will be used.
On no account ever use a raw UTC+n offset.
Past events had the local time, UTC, and time zone entry stored. Storage isn't much of an issue and it helped to keep things straight. Future events were only stored in local (8pm Dec 12, 2012) with time zone. Calculations were done on UTC with future events computing UTC on the fly. Reporting and actual day something occurred was kind of important. A day skipped would be an issue.
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.
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.
My question was what does Christianity do, and I guess no one here knows.
Wikipedia has a small breakdown for the 7th day in 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
It was my understanding that Catholics go with local to determine Sunday.
(1) http://en.wikipedia.org/wiki/Seventh-day_Adventist_Church
I'm not super familiar with the Muslim rules, but I know the Jewish rules have their own date line that does not correspond to the international one.
I don't know what the Christian rules are about the international date line and that's what I was asking.