Hacker News new | past | comments | ask | show | jobs | submit login
Samoa to jump forward in time by one day (bbc.co.uk)
111 points by JacobAldridge on May 9, 2011 | hide | past | favorite | 73 comments



For some historical context, losing one day is minor (as long as your birthday isn't 28 December) as compared to the 11 days that were 'lost' in the transition from Julian to Gregorian calendars.

And lest you think that's an historical artifact (to be fair, they didn't worry about sysadmins in Renaissance Rome circa 1582) many Orthodox / Eastern European countries like Russia, Greece, and Turkey made that change in the 1920s [1].

And yes, that's why Russia's October Revolution took place in November, 1917.

[1] http://en.wikipedia.org/wiki/Gregorian_calendar#Timeline


I was on a recent trans-Pacific flight where they announced after landing that one of the flight attendants had completely skipped over her birthday (we crossed the IDL at about midnight) so we gave her a round of applause for sacrificing her birthday in the name of duty.

I cross the IDL semi-frequently and it always depresses me. It depresses me when I completely skip a day going west, and it depresses me when I fly back the other way and have to live through the same day twice.


You just have to time your trips right, so you can, for example, trade a Wednesday for an extra Saturday.


Yeah, usually I travel on weekends so I wind up losing a Saturday and gaining an additional Monday.


Holy crap! Who in their right mind wants an extra Monday?


Here's a question that's purely hypothetical, and is so unlikely to ever need answering that is basically isn't worth asking, but I'm intrigued none-the-less.

Let's say there is <something> that requires a certain length of time, whether it is a 3 day waiting period to buy a gun (totally made up law, I have no idea about Samoan laws), or some prize given to any Samoan who turns 100 years old. Would it go by number of actual days, i.e. how many 24 hour periods have passed, or would it go by date?

Yeah, two terrible examples, and like I said, I doubt the answer would ever have any practical use. And for that reason, perhaps there is no definitive answer. Is there?


IANAL but I would have thought this is really no big deal.

If the stipulation is in days (eg 3 days cooling off) then 3 days is 3 days - the date doesn't matter.

If the stipulation is months or years, then the missing day is simply ignored.

I mean, we have a February 29 every 4 years. We already have "months" being an indeterminate number of days (28, 29, 30, 31). So December will have 30 days instead of 31. Big deal. Lots of countries have a time change twice a year, and it doesn't cause any major issues.

For the sake of computer "elapsed time" (interest calculations and so on) it's equally a non-event. The easiest way to handle interest for example is just to treat the missing day as if it had occurred. So it was a really short day, a holiday, which you slept through. Folks will still get paid for the "whole month" of December and so on.

I'm not sure what they'll do, but as long as it's trivially simple I suspect people will adapt very easily.

The worst that'll happen is that everyone will miss out on a whole Wednesday worth of TV. Bummer!


  Folks will still get paid for the "whole month" of December and so on.
Well, one example of how it could be problematic, is if someone is paid hourly (say a freelancer with a non-expiring fulltime-equivilent contract to a company). They would lose out on a day's pay, while their rent/other bills would still charge for one month, not for one month pro-rated down by one day.

As you said, different months have different lengths anyway, so it's not like an end-of-the-world problem, but for someone in that situation, they will none-the-less be losing money as a result of the change.

And as to your judgements on days vs months, it's fine to say "it doesn't have to be a problem if we do it like this", but when it comes to any sort of law or contract, that would rely on both parties agreeing, and it's not impossible that they would take opposite views to both try and improve the situation for themselves.

On a side note, if I were in Samoa, I would have great fun buying a 2011 calendar from as many shops as I could, then go round on December 29th complaining that it was factually incorrect and wanting a refund. Well, I say "I would...", in actual fact I wouldn't be quite that bored. But I like the idea of doing that.


>> As you said, different months have different lengths anyway, so it's not like an end-of-the-world problem, but for someone in that situation, they will none-the-less be losing money as a result of the change.

No, they're not really losing money, it's more like they're losing the opportunity to make money on that missing day. So a freelancer can, for example work in an extra day that week if they choose.

Public Holidays have the same effect every year, especially in countries where the actual day of the holiday follows the date, and thus in some years falls on a weekend.

Actually they've chosen to shorten a month which has 31 days to 30 days, which is no different than say April, June, September or November. So, by your measure they're being shorted for at least 5 months of every year anyway.

Plus, they've done it between Christmas and New Years, which in the Southern Hemisphere is the middle of the summer holidays. So pretty much no-one is working anyway.

The opposite way of looking at the same data is that they get a "free day" in every 31-day-month. And one of these "free days" is being discarded.

In other words, only us programmer types would try and nit-pick the thing apart. People on the ground haven't "lost" anything really.

My point about the contracts is that nothing is affected. Contracts that say "days" mean days, contracts that say months mean "months". This is built into contracts already because months aren't the same length. a 30 day December is no different to a 30 day April.


Legal contracts normally state "days" or "business days", and often then later specifically define these terms, e.g.

"Business Day means a day on which trading banks are open for business in London, United Kingdom excluding a Saturday, Sunday or public holiday."

This therefore leaves no room for doubt. A skipped day would not count as a day or business day.


More realistic examples: loans, fx swaps, or anything related to interest rates.



Care to elaborate? I'm aware there are conventions, but can't see how they help when you're compounding daily and a day disappears.

Say Bank A lends $10M to Bank B on Monday at 0.1% per day. On Tuesday B pays $1k to A. The following day is a Thursday. How much B owes A? $1k or $2k? $1k sounds reasonable but unless you modify your date library you'll probably get $2k.


typo: I meant 0.01% per day.


In theory, you should still have to wait the full period. But in practice, it depends on whether the software actually counts elapsed time like a stopwatch (unlikely) or just calculates a future date for release of the gun. As long as the system clock got updated, it would probably OK your gun a day early.


Here's a picture of the date line in that area: http://upload.wikimedia.org/wikipedia/commons/6/61/Internati...

There's one spot where you can cross the date line 3 times traveling strictly west to east and not changing your latitude!


Judging from the map, it looks like the Cook Islands and Tokelau, both NZ protectorates, could be the next to switch.


This could easily be a xkcd comic. What a mess...


It could have easily been a lot worse. It's a quirk of geography that the part of the world exactly 180 degrees from London, which just happened to be the capital of the world when the human race got around to setting up sensible time zones, happens to be a north-so-south slice of mostly unpopulated ocean, where only a few minor islands need to worry about this kind of thing.

Heck, there are a lot of possible globes where there's no sensible place to put an international date line at all... every north-south slice goes through a populated landmass.


And some of those are just our globe, rotated. (I'd give an example, but it's hard to come up with one because I don't have an actual globe that I can play around with.)


Put a pole bang in the middle of the largest landmass, Eurasia-Africa, and every line of longitude will cut through some temperate-zone habitable land.


Two years ago Samoa switched from driving on the right to driving on the left, to fit in with Aus/NZ http://news.bbc.co.uk/2/hi/asia-pacific/8243110.stm

This continues the broad change in foreign policy.


How long are we going to continue sharing this hallucination of "time zones"? Long live UTC, the one true time. Death to all the pretenders!


Until you can pursuade the majority of the world that they should have dark days and sunlit nights.


People would still get up when the sun shines and go to bed soon after it gets dark. You may be having lunch at 2200 but it'd still be near to when the sun was at its highest. The biggest problem I see would be elevenses would have to be changed in most places.


It would just make it even more confusing. Right now if I want to speak to a business contact in, say, America, I have to find out their time zone, work out what time it is, and call them up. Under the new system, I would know that my contact in Los Angeles has the same time as me, but I wouldn't know what that actually means. It's currently 1pm here in the UK, but at 1pm in LA will they be in the office? Will they be on their way home from work? Will they be fast asleep?

Obviously, it would be possible to learn these things, but it's much harder to look up. Imagine a table of different countries, how do you define this stuff? Much easier to define what time the 24 hour day starts based on the sun than to define people's behaviour, as not everyone will have the exact same schedule for when they start work, when they wake up, etc.


I think in practice it would work pretty similar to how it does now. Companies would set their own time guidelines (ie. "Most of us arrive between 2200 and 2300, but just make sure you're here by 2315 every day")

For scheduling meetings with people globally, you'd have to figure out the day/night cycle but I doubt it would be all that much different than it is now.

But! There would be no goofy daylight savings time differences and there would be no ambiguity ("Oops, I thought the meeting was at 1pm my time, not yours...").

Plus, all us programmers could sleep peacefully at night knowing that our time-based code would just work, instead of waking in a cold sweat wondering what will happen when a government across the globe decides to erase the existence of a day.


If I want to ring a company in another country I would rather be able to make an educated guess that has a 99% chance of success, such as "they will be at work at 2pm in their timezone" than have to look up that company's guidelines..


Except your "educated guess" right now has a good chance of being wrong due to the complexity of computing what time in your timezone corresponds to 2 pm in theirs.


Even now, you need to be aware of cultural differences, as well as timezones.

Examples: (for some definitions of here and there) It's 1300 here which means that it's 1700 there - do people tend to go home at 1700 or 1800?

Lunchtime in France is typically 1200-1400 (local), whereas in Israel it is 1400-1600. If I'm in France, and I need to call up my Israeli colleagues after lunch, simply adjusting for timezone won't do. If I call at 1430 Israeli time, they will have just gone out.

In these situations you currently have to know two things: what time it is over there, and what the cultural norms for work and mealtimes are. If time were internationally uniform, you'd only need the latter.


But it's certainly easier to guess right now. If I called and they were at lunch I would try again after the next hour clicks by, for example. And, in my experience, guessing at a 9-5 day has nearly always worked out for me, with just a few exceptions where I've learned of their slightly odd hours (and in my personal experience, all the people with odd hours are due to those people/companies, not the country they are in).


> In these situations you currently have to know two things: what time it is over there, and what the cultural norms for work and mealtimes are. If time were internationally uniform, you'd only need the latter.

For some time now I've included my time zone in the mouseprint of my email signature block; it'd be easy enough to include one's usual hours of availability as well.


It's currently 1pm here in the UK, but at 1pm in LA will they be in the office? Will they be on their way home from work? Will they be fast asleep?

With flexi-time and "24 hour working", that's becoming difficult with even the current system. I don't know the hours most of my contacts work but it frequently seems to be well into the small hours..


The US government, at least, thinks that the perception is relevant, else why did they put us through so much rigmarole in changing the dates of the Daylight Savings Time change?

EDIT: s/things/thinks/


Until we all stop living on a globe.


Our internal "clocks" are calibrated to the rising and setting of the sun with respect to our present location. Unless the Earth were literally flat and did not rotate on an axis, "universal time" would not work.


Why not? You think 5pm local time is just before evening due to convention. Your "internal clock" doesn't care what the clock on wall says. Here, 17:00 would just become lunch hour.


So you've traded timezones for lunchzones. Instead of calculating the timezone, you need to calculate when the local lunchtime is.

There is no net benefit.


You're right that there is no net benefit. But, as there's also no net detriment, it's still far from "wouldn't work."

I propose that we just drop DST, base local time on solar noon and calculate our associates' time based on their longitude.


...a great disturbance in the Net, as if millions of Samoan sysadmins cried out in terror and were suddenly silenced. I fear something terrible has happened.


But this is the easy one. Imagine the pain if they had to go backwards, repeating the same day twice!

(of course, we do that on a smaller scale in the USA once a year, when we set the clocks back from DST)


The comment about why they moved the calandar 119 years ago to be closer to the USA had me perplexed. I guessed it would have been too early for Samoa to get a telegraph station and therefore I couldn't understand the need to move the date. But looking at this http://goo.gl/wIaTb it seems to me that they got the telegraph in 1880 or there abouts...which precipitated the need for first change.


Similar problems are for people doing business in Europe and the Middle East. Some countries have Thursdays and Fridays off, others have Fridays and Saturdays. In Israel, Friday is a half working day.


I went to university in the West Bank for a year - we had Friday off, Saturday class, Sunday off. It was crazy.


If this interests you, and/or if you need to properly handle these kind of things in your code, it's good to keep up with the ZoneInfo/TZ Database and the associated mailing lists.

http://en.wikipedia.org/wiki/Tz_database http://cs.ucla.edu/~eggert/tz/tz-link.htm

Luckily for most people the ZoneInfo DB is part of the OS and gets updated with your system updates, but if you care about time in your app, you need to be aware of these.

Governments dictatorial and democratic alike love to screw with the engineers of the world by changing this stuff around all the damn time.


> Luckily for most people the ZoneInfo DB is part of the OS and gets updated with your system updates

Actually, that's NOT true, because most people use Windows, whose TimeZoneDB is horribly implemented, and only cares about the present (and only if you updated recently). If you ask it about 2003, it will answer with today's rules, not with the rules that were in effect in 2003.

While this is just a little bad for the US (rules changed only twice in the last 50 years), in some countries they have changed every other year, or they cannot be expressed with the rules that Windows has.

Windows date and time handling is a joke.


“Never trust Australians. They live a whole day in the future and they never tell us what’s going to happen.”

(I bet Samoa will join this conspiracy of silence when they make the jump.)


"In doing business with New Zealand and Australia, we're losing out on two working days a week."

Are not they gaining two days in the 5 day week. Just like US-India, there is always somebody from the company working and available due to the 12-13 hour gap.


Your example is talking about a company having longer working hours because half of it's staff are working at any one time (maybe with some overlap).

This change is because Simoa does business with people/companies in Australasia, so they want as much time when both time zones are working as possible, not to get the longest combined amount of work time between the two zones.

That said, because they are on the International Date Line, they are moving their calendar by exactly 24 hours, so their day/night (i.e. working hours) will still have the same relationship with those in Australasia. The difference is that, after this change, they will have five weekdays that overlap with Australasia's five weekdays, whereas right now they only have three, as demonstrated in the BBC story.


It doesn't say which day they'll skip.

I'd pick a Monday.


It does. They're skipping december 28, which is a Wednesday.


Sounds like somebody has a case of the Mondays :(


I believe you'll get your ass kicked, sayin' som'n like that, man.


Umberto Eco's "Island of the day before" is a funny novel built mostly around all the paradoxes and misunderstandings made possible by the existence of the IDL.

Not a chef d'oeuvre like "Foucault's pendulum" but well worth a read.

http://en.wikipedia.org/wiki/The_Island_of_the_Day_Before


I wonder if this would cause problems for daily cron scripts that run tasks by checking the date against == rather than than <. Not to mention monthly scripts that happen to run on that particular lost day.

Anyway, I love the passionate discussion programmers have when it comes to dates. Remember, it's only 86400 seconds that they are losing.


Anyone fancy going to a some websites, setting your time-zone to Samoa and putting 28 dec 2011 into some date fields (birthday, shipping date etc.) to see which ones crash?


Why not wait until the next leap day and skip that?


Maybe because time == money?


Well, the change is scheduled for December 28 this year, and the next leap day is February 29 of next year, so we're only talking two months here.

I assume the actual reason they chose that date is that they want to stick it in the xmas/NYE dead period which is mostly holidays anyway to minimise disruption.

Also, "time == money" is probably on the list of "things you're least likely to hear anyone say in Samoa".


Shouldn't the onus fall on the commercial sector to conduct business at the time that makes the most sense? If this means shifting the work week by a day for your employees so that you can do more business with your largest customers, then so be it.

This would yield flexibility, what about all the Samoan companies that still do most of their business with the US?


The Samoan companies that do business mainly with the USA are in a minority. They're also a heavily religious and family-oriented culture and aren't about to start working on Sunday. It sounds like you might be confusing Samoa with a more business-oriented culture.


So they just change the definition of when Sunday is to accomodate?


Yes. To quote Jesus Christ (in translation, of course :) "The Sabbath was made for man, not man for the Sabbath." Or to put it another way, you're only hurting yourself.

To be specific, the Sabbath is the last day of the week, so all the Christians who use Sunday both as the first day of the week and as their day of rest are already ignoring the Sabbath.

If you're interested in how that happened, it's to celebrate the resurrection of Christ, which was on the day after the Sabbath (because Jesus was crucified the day before the Sabbath and rose on the third day, the day after the Sabbath). So no matter where you put the Sabbath, Christians will still observe their day of worship on the day after.


Easier to do it that way. Just like how it's easier to devalue a currency for a nation rather than give every single individual in the country a pay cut!


Smart move - I was thinking whether this might act as a model of how other trading blocs to be more closely temporally clustered, but I think this is a special situation, facilitated by the date line and the geographical proximity of Samoa to Australia.

IOW - probably wouldn't work if eg India and Brazil wanted to get cosy.


im sorry samoa but, thats ridiculous. Whats going to be the date? are they also gonna skip a day like that? and a day isnt just some thing. its a pattern that dates back thousands of years just for them to disrupt that pattern


Even if you don't understand the basic concepts of the International Date Line, bother to read the article: it's not "a pattern that dates back thousands of years".

  The change comes 119 years after Samoa moved in the opposite direction.
What's going to be the date? Again, from the article you could see that they will skip from December 27th to December 29th, missing the 28th. So the date will be December 29th.

As to "a day isn't just some thing", a day is a 24 hour period as defined by how long it takes a planet to rotate on its axis. They aren't changing that, their days will still last 24 hours. Dates, however, are indeed just some thing, purely defined by humans, and there have been multiple different calendars over the years. See http://en.wikipedia.org/wiki/History_of_calendars

Samoa sits practically right on the International Date Line, this is the line where GMT -12 meets GMT +11, so that you are travelling forwards or back 24 hours whenever you cross over it, depending on your direction. Therefore, whichever side of the IDL they chose to base their time and date on, the time will still fit the day as we know it (i.e. dark at night). And, whichever side of the IDL they chose to base their time on, there will always be other islands very, very close to them that are 24 hours (i.e. one whole day) away from them.

Ultimately, the only difference this makes is whether their weekends coincide with those of the Americas, or those of Australasia. Since, in the past 119 years, their businesses have moved from mostly dealing with the Americas to mostly dealing with Australasia, so it makes sense to move back to being in sync with Australasia.


1) They just picked a new time zone which is more convenient for doing business with their neighbours. No dates disappeared, the new time zone just happens to be off-set 24 hours from the old one. Timestamps can still be converted between the old and the new time-zone, just like you can do the conversion for any other pair of time-zones.

2) The Gregorian calendar was introduced in 1582, not "thousands of years" ago.


Did you... read the article?


For quite some years every other Sunday I'd leave home1 early evening and arrive at home2 early Tuesday morning, having travelled on average about 21 hours (all those mandatory inspections of my underpants, you see), thereby skipping an awful lot of Mondays.

A day really is just a thing: I'm not any younger.


While you're right that crossing the IDL doesn't make you a day older or younger... there is a slight flaw in your logic. In order for you to have gone forward a day every two weeks, you must have come back a day in between, as well.

After all, it's possible to fly around the world in less than 24 hours, but you can't use that to travel forward or backwards in time, you can only ever get to a maximum of 24 hours ahead or behind of another place.


Perhaps I was too dry: everything you say is true, but you kinda missed the point ;)

Edit: In retrospect realise that wasn't particularly helpful. I skipped an awful lot of Mondays for which the only consequence was utter joy at the two cocktail hours every other Saturday. Contrary to the great grandparent, a day really is just a thing.


Sorry, I wasn't clear enough - I didn't miss the point you were making, and I completely agree with it (one of my other comments somewhere on this page makes that same point), I was just pointing out the flaw in your example that travelling forward through time zones many times won't make more of a difference than doing it just once.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: