A brief history of time zones
March 25, 2011 11:54 AM Subscribe
The BBC looks at time zones - how they are worked out, why they cause so many arguments, and how they affect us all. (via)
Eventually every programer out there has a project where they have to deal with time zones and daylight savings time and it's amazing how quickly something that seemed so simple and obvious is filled with gotchas. Plus you get another reason to hate Arizona! Double win!
posted by aspo at 12:13 PM on March 25, 2011 [7 favorites]
posted by aspo at 12:13 PM on March 25, 2011 [7 favorites]
Yup. Time zones are the bane of my programming existence.
posted by Lokheed at 12:16 PM on March 25, 2011 [3 favorites]
posted by Lokheed at 12:16 PM on March 25, 2011 [3 favorites]
Ah, I get to plug one of my favorite websites. Very useful.
posted by Xoebe at 12:21 PM on March 25, 2011 [1 favorite]
posted by Xoebe at 12:21 PM on March 25, 2011 [1 favorite]
Theoretically the world should be divided into 24 equal time zones, in which each time zone differs from the last by one hourTheoretically there should be no discrete time zones, and time would continuously vary, by minutes seconds per degree of longitude. (4 seconds per minute of longitude) That would be a pain in the butt though, so we don't do that. But time zones are a pain in the butt too, it turns out, so: oh well.
posted by aubilenon at 12:27 PM on March 25, 2011 [5 favorites]
Theoretically there should be no discrete time zones, and time would continuously vary, by minutes seconds per degree of longitude.
Maybe you could do that once GPS-enabled smartphones become ubiquitous. The time would change depending on where you are, and appointment and meeting times could be synced automatically. Your navigation software could tell you when you need to leave (local time) to make sure you arrive at the right time for your destination.
Alternatively, screw time zones and go with one world time, but shift the day an hour every few months so no one gets the short end of the daylight stick.
posted by Rock Steady at 12:39 PM on March 25, 2011
Maybe you could do that once GPS-enabled smartphones become ubiquitous. The time would change depending on where you are, and appointment and meeting times could be synced automatically. Your navigation software could tell you when you need to leave (local time) to make sure you arrive at the right time for your destination.
Alternatively, screw time zones and go with one world time, but shift the day an hour every few months so no one gets the short end of the daylight stick.
posted by Rock Steady at 12:39 PM on March 25, 2011
I'm glad they talk about the maddening Pakistan/India/Nepal time zone situation. Pakistan is GMT+5 (which is fine) while India is GMT+5.30 (which is wacky and confusing). Like they needed to be that exact, considering they are applying a time zone to a country that is more than 2,000 miles across and covers 28 degrees of longitude. Then Pakistan went and adopted daylight savings time, so now they are GMT+6 in the summer, which is half an hour ahead of India to its east. And then there's Nepal, who, out of some misguided sense of national pride, sets their time to GMT+5.45, putting them out of sync with the entire world. Except for, I guess, the Chatham Islands.
posted by bookish at 12:50 PM on March 25, 2011
posted by bookish at 12:50 PM on March 25, 2011
Alternatively, screw time zones and go with one world time, but shift the day an hour every few months so no one gets the short end of the daylight stick.
Or they could just get used to dawn being at 15:00 and sunset at 03:00 or whatever. Sort of like Australia having summer in December.
posted by gubo at 1:02 PM on March 25, 2011 [3 favorites]
Or they could just get used to dawn being at 15:00 and sunset at 03:00 or whatever. Sort of like Australia having summer in December.
posted by gubo at 1:02 PM on March 25, 2011 [3 favorites]
Eventually every programer out there has a project where they have to deal with time zones and daylight savings time and it's amazing how quickly something that seemed so simple and obvious is filled with gotchas. Plus you get another reason to hate Arizona!
My family went on an extended vacation to Nevada, Utah, and Arizona when I was in high school. First we all switched our watches back to Pacific Time when we got to Nevada, then crossed into Utah -- and learned that whoops, Utah is on Mountain time, so we had to set our clocks ahead. Then we crossed into Arizona -- whoops, Arizona doesn't do Daylight Savings Time, so we had to set the clocks back again. Then we crossed into Utah again -- oh, yeah, it DID do Daylight savings time. It seemed like every time we crossed a border we had to futz with our clocks, even though we were traveling under a hundred miles to get from one point to another.
Then finally we ended up at Lake Powell, which was half in Arizona and half in Utah; and that's when Dad just got totally confused and stopped someone and asked them in desperation, "Excuse me, but what time is it in the spot I'm standing in right now?"
posted by EmpressCallipygos at 1:11 PM on March 25, 2011 [4 favorites]
My family went on an extended vacation to Nevada, Utah, and Arizona when I was in high school. First we all switched our watches back to Pacific Time when we got to Nevada, then crossed into Utah -- and learned that whoops, Utah is on Mountain time, so we had to set our clocks ahead. Then we crossed into Arizona -- whoops, Arizona doesn't do Daylight Savings Time, so we had to set the clocks back again. Then we crossed into Utah again -- oh, yeah, it DID do Daylight savings time. It seemed like every time we crossed a border we had to futz with our clocks, even though we were traveling under a hundred miles to get from one point to another.
Then finally we ended up at Lake Powell, which was half in Arizona and half in Utah; and that's when Dad just got totally confused and stopped someone and asked them in desperation, "Excuse me, but what time is it in the spot I'm standing in right now?"
posted by EmpressCallipygos at 1:11 PM on March 25, 2011 [4 favorites]
It used to be worse in Indiana. The Central time zone parts followed Daylight Saving Time while the Eastern time zone parts didn't. Fixing that was the one and only thing that Mitch Daniels has ever done right.
I wish our whole state was on Central time. We're too far west for Eastern time so my kids have to get on the school bus while it's still pitch black outside during the winter.
posted by double block and bleed at 1:19 PM on March 25, 2011 [2 favorites]
I wish our whole state was on Central time. We're too far west for Eastern time so my kids have to get on the school bus while it's still pitch black outside during the winter.
posted by double block and bleed at 1:19 PM on March 25, 2011 [2 favorites]
We're too far west for Eastern time so my kids have to get on the school bus while it's still pitch black outside during the winter.
I grew up here in New Jersey, and this was still the case...
posted by ego at 1:24 PM on March 25, 2011
I grew up here in New Jersey, and this was still the case...
posted by ego at 1:24 PM on March 25, 2011
I have no idea why the UK wants to introduce more time zone complexity. I'd advocate for the US switching to two time zones, one for the east and one for the west...no more scratching your head to figure out when you're supposed to call someone in Indiana.
posted by miyabo at 1:31 PM on March 25, 2011
posted by miyabo at 1:31 PM on March 25, 2011
Time zones are the bane of my programming existence.
Time is the bane of programming existence.
For example, what's Today + 1 month? Is it next month, same day? Is it next month, one or two days less (depending on which month you're adding)? Is it next month, same day, minus fucking 1 because every single goddamned programming language uses fucking base-0 for month but base-1 for every single other fucking field?! AAARGH.
breath breath calm down, it's friday breath breath
posted by Civil_Disobedient at 1:46 PM on March 25, 2011 [5 favorites]
Time is the bane of programming existence.
For example, what's Today + 1 month? Is it next month, same day? Is it next month, one or two days less (depending on which month you're adding)? Is it next month, same day, minus fucking 1 because every single goddamned programming language uses fucking base-0 for month but base-1 for every single other fucking field?! AAARGH.
breath breath calm down, it's friday breath breath
posted by Civil_Disobedient at 1:46 PM on March 25, 2011 [5 favorites]
Ah, I get to plug one of my favorite websites. Very useful.
Wow, that's a great site. I didn't know that Hawaii doesn't do daylight savings time, so it's 6 hours earlier than the east cost in the summer, I guess!
posted by leahwrenn at 2:07 PM on March 25, 2011
Wow, that's a great site. I didn't know that Hawaii doesn't do daylight savings time, so it's 6 hours earlier than the east cost in the summer, I guess!
posted by leahwrenn at 2:07 PM on March 25, 2011
Also, fun with daylight savings time: did you know that right now the UK is four hours ahead of the US East Coast, instead of five? In general all time differences between the EU and the US/Canada are one hour less than you think they should be.
That's because North America does daylight savings time shifts this year on March 13 and November 6 (generally, second Sunday of March and first Sunday of November) while the EU does them on March 27 and October 30 (generally, last Sunday of March and last Sunday of October). So there's a period every spring and a period every fall where the difference is one hour less than usual.
Under the pre-2007 US rules, the US DST period was shorter than the EU one, so there was no such period in the fall, and there was a period in the spring where the difference was one hour more than usual.
posted by madcaptenor at 3:06 PM on March 25, 2011
That's because North America does daylight savings time shifts this year on March 13 and November 6 (generally, second Sunday of March and first Sunday of November) while the EU does them on March 27 and October 30 (generally, last Sunday of March and last Sunday of October). So there's a period every spring and a period every fall where the difference is one hour less than usual.
Under the pre-2007 US rules, the US DST period was shorter than the EU one, so there was no such period in the fall, and there was a period in the spring where the difference was one hour more than usual.
posted by madcaptenor at 3:06 PM on March 25, 2011
I'm glad they talk about the maddening Pakistan/India/Nepal time zone situation. Pakistan is GMT+5 (which is fine) while India is GMT+5.30 (which is wacky and confusing).
Actually growing up in India the GMT +5.30 made perfect sense. The problem is the +5 and +6 lines are on the extreme west and extreme east of the country respectively, so either option doesn't really work for the entire country. And having two time zones is inconvenient, especially since in some ways links between cities on opposite sides of the country are stronger than between a major city and the regions surrounding it. Time zones are pretty arbitrary anyway, and there were never any big problems with having a time zone that wasn't x hours away from GMT. I'm certainly a lot less confused by it than by Daylight Savings -- why can't we just have Daylight Savings all the time?
posted by peacheater at 3:21 PM on March 25, 2011
Actually growing up in India the GMT +5.30 made perfect sense. The problem is the +5 and +6 lines are on the extreme west and extreme east of the country respectively, so either option doesn't really work for the entire country. And having two time zones is inconvenient, especially since in some ways links between cities on opposite sides of the country are stronger than between a major city and the regions surrounding it. Time zones are pretty arbitrary anyway, and there were never any big problems with having a time zone that wasn't x hours away from GMT. I'm certainly a lot less confused by it than by Daylight Savings -- why can't we just have Daylight Savings all the time?
posted by peacheater at 3:21 PM on March 25, 2011
Programming with time is easy. Do absolutely all calculations in UTC, and set your server clocks to UTC as well. If you absolutely must display time to an end user (sysadmins don't count), then convert at the last possible moment: ideally in Javascript on the client machine. Problem solved! (Unless you care about 1 second accuracy, in which case leap seconds may be an issue).
See also draft-lear-iana-timezone-database-01, where IANA tries to cope with the fact the lone genius who's kept time zones straight on computers for 20 years is retiring.
See also draft-lear-iana-timezone-database-01, where IANA tries to cope with the fact the lone genius who's kept time zones straight on computers for 20 years is retiring.
The database itself is updated approximately twenty times per year, depending on the year, based on information these experts provide to the maintainer. Arthur David Olson has maintained the database, coordinated the mailing list, and provided a release platform since the database's inception. With his retirement now approaching it is necessary to provide a means for this good work to continue. The Internet community owes Arthur Olson and the volunteers on the tz mailing list a debt of gratitude.posted by Nelson at 3:40 PM on March 25, 2011 [3 favorites]
I didn't know that Hawaii doesn't do daylight savings time, so it's 6 hours earlier than the east cost in the summer, I guess!
Later, but yes.
Also: Fucking time zones, how do they work?
posted by nevercalm at 3:44 PM on March 25, 2011
Later, but yes.
Also: Fucking time zones, how do they work?
posted by nevercalm at 3:44 PM on March 25, 2011
It was only a couple of days ago that I went looking for a Greasemonkey script that would automatically add to every mention of local time a translation into my time zone, e.g.:
'x:xx EST' would become: 'x:xx EST (y:yy in your time)', or something like that.
I couldn't find it but wouldn't that be totally handy?
posted by mahershalal at 5:10 PM on March 25, 2011
'x:xx EST' would become: 'x:xx EST (y:yy in your time)', or something like that.
I couldn't find it but wouldn't that be totally handy?
posted by mahershalal at 5:10 PM on March 25, 2011
mahershalal: that seems difficult, because people don't tag times with time zones in a standardized way. I could imagine people writing "x:xx EST" or "x:xx Eastern time" or even "x:xx New York time", and people sometimes use EST when they really mean EDT, and so on...
posted by madcaptenor at 5:51 PM on March 25, 2011
posted by madcaptenor at 5:51 PM on March 25, 2011
Programming with time is easy. Do absolutely all calculations in UTC, and set your server clocks to UTC as well.
Especially now that GPS distributes UTC with very high accuracy, worldwide...
... and then leap seconds come along. Stupid earth, can't even stick to the same rotation speed.
posted by phliar at 6:09 PM on March 25, 2011
Especially now that GPS distributes UTC with very high accuracy, worldwide...
... and then leap seconds come along. Stupid earth, can't even stick to the same rotation speed.
posted by phliar at 6:09 PM on March 25, 2011
Just display UTC timestamps to the user. If they don't know what "1301102409" means, too bad.
posted by double block and bleed at 6:21 PM on March 25, 2011
posted by double block and bleed at 6:21 PM on March 25, 2011
If you absolutely must display time to an end user (sysadmins don't count), then convert at the last possible moment: ideally in Javascript on the client machine. Problem solved!
Well, no, not really. Let's say a customer buys something from a store in California at 3:00pm. The authorization servers that retain the information from the transaction are located in Massachusetts. The web server that displays the customer logs into to view their transaction history is located in Nebraska. The customer logs into their web account while on vacation in England.
What time does it show them the transaction was made?
If you convert the time to the client's local TZ at the last possible moment as you suggest, you get the time relative to England, which is 10pm. But you didn't buy it at 10pm... heck, the store wasn't even open at that point. If you convert the time to the server's locale, you again get it wrong. You basically have to save the time zone information along with the date/time, otherwise you have no reference for re-calculating the display.
posted by Civil_Disobedient at 6:54 PM on March 25, 2011
Well, no, not really. Let's say a customer buys something from a store in California at 3:00pm. The authorization servers that retain the information from the transaction are located in Massachusetts. The web server that displays the customer logs into to view their transaction history is located in Nebraska. The customer logs into their web account while on vacation in England.
What time does it show them the transaction was made?
If you convert the time to the client's local TZ at the last possible moment as you suggest, you get the time relative to England, which is 10pm. But you didn't buy it at 10pm... heck, the store wasn't even open at that point. If you convert the time to the server's locale, you again get it wrong. You basically have to save the time zone information along with the date/time, otherwise you have no reference for re-calculating the display.
posted by Civil_Disobedient at 6:54 PM on March 25, 2011
Eleven....
posted by pdxjmorris at 9:53 PM on March 25, 2011
posted by pdxjmorris at 9:53 PM on March 25, 2011
If you convert the time to the server's locale, you again get it wrong.
I think the idea is that you never convert to the server's locale, you convert on the client side to the user's locale. So if you are viewing the site from England, than the timestamps are converted to GMT ... so if you ordered something in the US at 1400 EDT on Monday and then flew to London and viewed your account, it wouldn't be wrong to show that the order was placed at 1800 GMT. (Because EDT is 'GMT minus 4', so 1400 EDT is 1800 GMT.) The server — all the servers — would store the timestamps as UTC or Unix epoch seconds or some other neutral format, and then you convert to the desired local timezone when you go to display it.
Sure, depending on the application you might want to take the place that the order was made from into account but I can think of lots of places where it wouldn't matter. (If I want to know when a package that I'm awaiting shipped from New York, and I'm in London, I don't really give a crap what time in EDT it shipped out, I probably want to know it in London time.)
I'm pretty certain that FedEx's and UPS's sites work this way actually. I don't think they do the calculations in JavaScript, but they try to localize stuff for the viewer, I'm pretty sure. I don't have a tracking number for a package that's crossed time zones to check, though.
posted by Kadin2048 at 10:43 PM on March 25, 2011
I think the idea is that you never convert to the server's locale, you convert on the client side to the user's locale. So if you are viewing the site from England, than the timestamps are converted to GMT ... so if you ordered something in the US at 1400 EDT on Monday and then flew to London and viewed your account, it wouldn't be wrong to show that the order was placed at 1800 GMT. (Because EDT is 'GMT minus 4', so 1400 EDT is 1800 GMT.) The server — all the servers — would store the timestamps as UTC or Unix epoch seconds or some other neutral format, and then you convert to the desired local timezone when you go to display it.
Sure, depending on the application you might want to take the place that the order was made from into account but I can think of lots of places where it wouldn't matter. (If I want to know when a package that I'm awaiting shipped from New York, and I'm in London, I don't really give a crap what time in EDT it shipped out, I probably want to know it in London time.)
I'm pretty certain that FedEx's and UPS's sites work this way actually. I don't think they do the calculations in JavaScript, but they try to localize stuff for the viewer, I'm pretty sure. I don't have a tracking number for a package that's crossed time zones to check, though.
posted by Kadin2048 at 10:43 PM on March 25, 2011
why don't they just use an individual time zone decided by the capital, but get up to work according to local daylight? ie, Australian "Time" but get up at 3am and finish work at 1230pm, with your employer stating what time you work.
I mean we already post opening and closing times. You'd still have the rule of thumb around sunset etc to know when shops clothes.
I mean I do shift work so i'm used to viewing time in an arbitrary way, (i used to use the Einstein quote on the subject when I was late for school ;) so perhaps I'm a bit biased and have no problem dealing with the ambiguity. I remember sitting in physics class and working out with a friend how many minutes we would lose for every kilometre we travelled east/west.
posted by Dillonlikescookies at 4:47 AM on March 26, 2011
I mean we already post opening and closing times. You'd still have the rule of thumb around sunset etc to know when shops clothes.
I mean I do shift work so i'm used to viewing time in an arbitrary way, (i used to use the Einstein quote on the subject when I was late for school ;) so perhaps I'm a bit biased and have no problem dealing with the ambiguity. I remember sitting in physics class and working out with a friend how many minutes we would lose for every kilometre we travelled east/west.
posted by Dillonlikescookies at 4:47 AM on March 26, 2011
China has one time zone despite really needing about 5 or so.
A problem with formatting time on the client is that clients often have poorly synchronized clocks. I've seen JavaScript that figures out what TZ you're in by the time on your machine, then gets accurate time from the server in that TZ and uses it... Not a simple process though.
Also don't forget that big, old organizations often have their own completely independent time representations that are not trivial to convert to UTC. Heck, I worked at a company that did bus schedules and the standard way to do time representation in that area is really annoying because routes that cross over midnight are recorded on the previous day -- so you have times in your database like 2600 to represent an incident on a route at 2 am when the route started before midnight. Another workplace used days past the beginning of the fiscal year (with decimals if necessary). Which time zone was that in? No one knew!
posted by miyabo at 7:04 AM on March 26, 2011
A problem with formatting time on the client is that clients often have poorly synchronized clocks. I've seen JavaScript that figures out what TZ you're in by the time on your machine, then gets accurate time from the server in that TZ and uses it... Not a simple process though.
Also don't forget that big, old organizations often have their own completely independent time representations that are not trivial to convert to UTC. Heck, I worked at a company that did bus schedules and the standard way to do time representation in that area is really annoying because routes that cross over midnight are recorded on the previous day -- so you have times in your database like 2600 to represent an incident on a route at 2 am when the route started before midnight. Another workplace used days past the beginning of the fiscal year (with decimals if necessary). Which time zone was that in? No one knew!
posted by miyabo at 7:04 AM on March 26, 2011
Oh geez, I was being facetious that doing all work in UTC and converting at the last possible moment solves all problems. It solves some basic problems, particularly for simple applications, but certainly not all. Doing all server work in UTC is the first step to making things work, not the last.
Fedex has a drop-down on its tracking page for time zone. Your options are "Local Scan Time" (the default), "Origin", "Destination", and "Others" (force all times to a user selected timezone). Conversions are done client-side, in Javascript. (Related, oh god when will my iPad 2 get here from China?)
Note: in Javascript you can format UTC timestamps to local time without giving a damn what the client computer's clock says.
Fedex has a drop-down on its tracking page for time zone. Your options are "Local Scan Time" (the default), "Origin", "Destination", and "Others" (force all times to a user selected timezone). Conversions are done client-side, in Javascript. (Related, oh god when will my iPad 2 get here from China?)
Note: in Javascript you can format UTC timestamps to local time without giving a damn what the client computer's clock says.
new Date(1301150957000)posted by Nelson at 7:51 AM on March 26, 2011
Sat Mar 26 2011 07:49:17 GMT-0700 (Pacific Daylight Time)
Nepal's wacky time zone actually makes sense if you think of its location. It's a country that borders India and Chinese-ruled Tibet. These (comparative) superpowers aren't at war but there's certainly some degree of tension between them. Nepal really, really, doesn't want either neighbour to think that it's siding with one over the other, and since India has a timezone that's 30 minutes out, Nepal is effectively forced to have one that's 15 minutes out.
posted by Joe in Australia at 4:13 PM on March 26, 2011
posted by Joe in Australia at 4:13 PM on March 26, 2011
"What kind of shmuck-ass system can this possibly...??"
posted by -->NMN.80.418 at 12:58 AM on March 27, 2011
posted by -->NMN.80.418 at 12:58 AM on March 27, 2011
Kadin2048 wrote: "I'm pretty certain that FedEx's and UPS's sites work this way actually. I don't think they do the calculations in JavaScript, but they try to localize stuff for the viewer, I'm pretty sure. I don't have a tracking number for a package that's crossed time zones to check, though."
They've both had recent redesigns of their tracking systems, so I'm not quite sure how it is currently, but pre-redesign, all times were (by default) in the local time of the reporting station. (or the package, if you prefer)
I'm pretty sure DHL worked the same way.
posted by wierdo at 12:01 PM on March 27, 2011
They've both had recent redesigns of their tracking systems, so I'm not quite sure how it is currently, but pre-redesign, all times were (by default) in the local time of the reporting station. (or the package, if you prefer)
I'm pretty sure DHL worked the same way.
posted by wierdo at 12:01 PM on March 27, 2011
madcaptenor: "people sometimes use EST when they really mean EDT, "
This is one of my pet peeves. People are always saying, "We'll run this process at 8 am EST" in documents. Oh, you'll be doing it at 9 am in the summer, then?
posted by Chrysostom at 10:18 PM on March 30, 2011
This is one of my pet peeves. People are always saying, "We'll run this process at 8 am EST" in documents. Oh, you'll be doing it at 9 am in the summer, then?
posted by Chrysostom at 10:18 PM on March 30, 2011
« Older It's On Like Harper Kong | Thanks for the memories Newer »
This thread has been archived and is closed to new comments
posted by BeerFilter at 12:05 PM on March 25, 2011 [5 favorites]