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.
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.
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.
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?
> 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.
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.
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
The last system I had to do that had to have good dates - I did the following:
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.
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.
what? no, that is a horribly convoluted solution to account for a rare edge case. store UTC and an olson string, and if people live in an area where the dates change, it is their responsibility to move their appointments. if you want to be really nice, you could run a batch job to switch all effected events a day forward.
I disagree -- in this case, you should consider storing local time and the Olson tz it's due to be in. Microsoft make the mistake of doing it your way in Outlook, meaning that everyone had to update their calendars when the US changed their DST rules.
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.
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.
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.
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).
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).
What's to follow? It's just a one-time change that makes a lot of sense given their location. They aren't permanently getting rid of Friday. Besides, Hebrew and Muslim calendars are lunar-based and I would imagine not affected by this.
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.