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."
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.
But how does Thailand handle unixtime? It's already year 2555 there. That's way past 32-bit int.
This happened to me once. I crossed the International Date line on December 24. It was December 26 on the other side. It was the year without a Christmas.
Hoist Number One and Number Six.
This makes me wonder. Are people going to be paid/charged interest for a non-existing 12-30-11 there?
If you go to north pole and keep running around the pole in same direction, crossing timezones, you can go infinitely back or forward in time!
just count on your knuckles from left to right (both hands); each big knuckle - {31}, each small knuckle - [28-30]
According to wikipedia (admittedly with a "citation needed") the seven day week cycle has continued unbroken for almost two millenia, despite numerous readjustments in the date over the centuries. So although skipping even a whole bunch of dates is not unheard of (e.g., Thursday, October 4th, 1582 followed immediately by Friday, October 15th when the Gregorian calendar was adopted), this seems like the first time in a long time that the day after Thursday hasn't been Friday.
s/small knuckle/valley between knuckles/ :-)
Yes. Apparently they're paying people who were scheduled to work on Dec. 30. I assume they'll charge interest too.
Until you hit that darn international date line.
... however it's not that effective as locale is not taken into consideration. As your link mentions, "only" England+Scotland+colonies switched at that point.
- Peter Brodersen; professional nerd
[Disclaimer: I live there]
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.
And they'd get to say that they were "leaping" over leap day....
That might be convenient for making appointments for telephone conferences, but it really sucks if you actually travel to such a timezone and need to schedule your daily program; then you will have to calculate the offset relative to your old place every time you wonder whether it is already lunch time, or whether the shops/offices are open. Not to mention that having the date and day of the week change in the middle of the day might also be rather inconvenient: what does "see you on Wednesday" mean?
And as for appointments: calendar applications already take care of calculating the time zones while scheduling meetings.
Avantslash: low-bandwidth mobile slashdot.
Just jump over it.
What will this do to the supply of Girl Scout Samoa cookies? (For the record, I hoarded Manila folders when the Marcos government fell.)
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.
But how does Thailand handle unixtime? It's already year 2555 there. That's way past 32-bit int.
Considering that Unixtime only started in 2514.
Epoch fail.
Calling someone a "hater" only means you can not rationally rebut their argument.