Slashdot Mirror
Samoa and Tokelau Are Skipping December 30th
ocean_soul writes "Starting January 1, 2012 Samoa and Tokelau will be in time zone +13 instead of -11. This means there will be no December 30, 2011 in these countries. The decision to switch time zone was based on the changing international business relations of Samoa. Samoa had adopted the -11 time zone to make business with the U.S. easier. However, currently Samoa's most important trading partners are Australia and New Zealand. By switching time zone the work-weeks and week-ends on Samoa and Tokelau will be synchronized with those in Australia and New Zealand."
If they change on January 1, then December 30 would already been passed at that point. So, that would mean it's already Dec 30 there right now and it cannot be Jan 1 yet according to any time zone. The math is fail.
No change in time. -11 = +13 mod 24.
The only change is the date.
General Relativity: Space-time tells matter where to go; Matter tells space-time what shape to be.
just count on your knuckles from left to right (both hands); each big knuckle - {31}, each small knuckle - [28-30]
Marry someone from Canada and you can have Thanksgiving twice a year every year (or the other way if you are Canadian).
Until you hit that darn international date line.
Does current time code even have the sufficient smarts currently to handle specific countries CHANGING their TZ on a particular date?
Yes. Linux/Unix has a long history of tracking timezone changes for specific countries, states, provinces, etc. It's called the Olsen Timzone Database. It was recently taken over by IANA, and is hosted here http://www.iana.org/time-zones
They are discussing this specific issue here:
http://mm.icann.org/pipermail/tz/2011-December/008458.html
This makes me wonder. Are people going to be paid/charged interest for a non-existing 12-30-11 there?
It depends. I work for a time and attendance company as software developer, so I have some insight. Basically, this is handled just like a DST change, but for a much longer period.
Many timekeeping systems (hardware and software alike) just keep track of "local time". Some have the ability to keep a list of DST changes that need to be applied at specific times, and some use NTP or other protocols to sync their clocks and pickup timezone changes that way. While these systems handle "spring-forward" changes ok, they are usually flawed in the way they handle "fall-back". If someone clocks in or out DURING the fall-back period, there is no way to tell if they get an extra hour or not, because there is no recorded distinction between the two times that are both called the same thing. The good thing about DST is that the change usually happens in the middle of the night, which minimizes the number of manual corrections that have to be made.
The solution to all of this, of course, is recording time as UTC and converting it for proper display depending on context. Some systems out there caught on early, but really this idea is just now making its way into the market. This is where the timezone database is very valuable. Windows also has a timezone database (different than the Olsen DB), but Microsoft only pushes it out every few months (via windows update), so it is often behind in various parts of the world. Microsoft timezone info here: http://blogs.technet.com/b/dst2007
Since Samoa and Tokelau are skipping a day, this is a "spring-forward" scenario - which is very easy to calculate. It is highly unlikely that they will have issues with paying an extra day (or charging an extra day's interest), as long as they consider the change like any other DST change. I would think that this is big news there, so anyone with custom code will probably be aware of the situation and make the correction.
Of course, if you have a bank account in another country, they are going to say a big "screw you" to your request to be charged one day's less interest just because your homeland is skipping a day. :)
No, actually it's not.
First, UT is a bit confusing. You have to specify which UT you mean: UTC, UT0, UT1, UT1R, etc...
All these, except UTC, are based on celestial movement. Which means they will vary due to natural causes. A slight wobble in Earths orbit or a little bit of tectonic shift will cause seconds to be shorter or longer. UTC is based on 'artificial' timing (atomic timekeeping) and as such has slightly different seconds than the other UT's.
So, no, UTC is not simply another UT without counting leap seconds.
Timekeeping is hard. Really hard.
Their work-week is now in sync with Aust and NZ, rather than only having four days that coincide.
I apologize for sidetracking the discussion to the leap second issue. Let me try again: "seconds since the UNIX time epoch, counting any leap seconds as 0 instead of 1". This makes each midnight-to-midnight period 86400 seconds long. My point is that the UNIX time epoch is the same regardless of the local civil calendar's epoch.