The Problem with Time & Timezones - Computerphile

sooner or later every programmer has to deal with time zones and i can't really offer much advice here i can offer a cautionary tale um i can tell you why you really should never ever deal with time zones if you can help it let's imagine that someone has has built an application that lets you calculate how many seconds something is in the past if you type in a date and a time it gives you the number of seconds and they look at that and think okay that kind of works for me but let's let's add a little box that lets you change the time zone so if you're you know if you're comparing between now in new york and five days ago in london you can work that out and that's fine you know the little drop down lets you change which hour forward or backward of greenwich you are brilliant sooner or later after it gets a bit popular they'll get a call from australia and australia will say good day i'm not going to try and do accents um i just shouldn't do accents um australia will say hello um by the way we're nine and a half hours ahead of greenwich and the program will go really i'll say yeah yeah nine and a half hours so okay i'll have a special case for you that's fine a little bit later someone will call from nepal and they'll say hello um we're five and a quarter hours ahead of greenwich and they'll say really i say yeah yeah we've been that for ages yeah five and a quarter hours great okay and they'll and they'll put in a special case and maybe they'll look up the list of time zones the canonical list that tells you what everything is i'll make sure they've covered every time zone in the world and then autumn will come along and we'll get a call from england and uh england will say excuse me um we're an hour out at the minute what's going on and they'll hold on the clock's just changed that's fine no no we dealt with that we dealt with that we made a note of when daylight saving changes for us and we put that in and and england will say no see daylight saving changes a week earlier for us it's different depending on where you live we we shift our clocks back a week before you do and at that point that point generally the program will start to hold their head in their hands and realize what they've got themselves into and that's fine you know they'll put that in and they will deal with each country shifting to daylight savings time on a different day and they'll look at the file that tells them how to do that and i'll copy all that in and then they'll get a call from someone in the southern hemisphere again who will say yeah we're not shifting back in the autumn we shift forward our our spring is in november and and that point they'll generally start looking longingly at their intoxicant of choice and wondering whether they should have a quick drink before keeping going and and then they'll they'll code that in as well and then they'll get a call from samoa uh out in the pacific on the international date line and tomorrow will say hello um yeah we we skipped today the other year and the program will say what so yeah we skipped today we went from december the 29th 2011 to december the 31st we we shifted from one side of the international dateline from being hours and hours behind greenwich to being hours and hours ahead of greenwich helps us with trading with australia can you take account of that when you work out how many days things are and how many seconds things are in the past that's fine there's a there's a file that tells you when any country has changed its time zone it turns out that that happens fairly often but they're announced ahead of schedule so as long as you keep that file updated and code that into your program's logic as well it'll be fine then you look back and you notice that during world war ii england had double british summer time it went completely onto bst and then just added an extra hour so it was two hours ahead of greenwich despite having greenwich that's fine you deal with that it's changed if you notice i'm starting talking as if as if it was you or me because i've done this before and it's really really frustrating you make sure that you subscribe to the list of when countries are going to change their time zones which happens apparently many times like sometimes several times in a year because governments change over and then then the program this this mythical programmer gets a call from libya who in 2013 with only a couple of days notice decided that they weren't going to put the clocks back with enough notice that it wasn't possible for anyone to get the update out in time and meaning that every libyan computer no matter what operating system it ran was an hour out if it's okay you you read the news article about that and you hurriedly code that in as well and then then you get a call from the west bank where the israeli population is on a different time zone to the palestinian population because one is following israel and one isn't and now you have two populations of people in the same location who are following different time zones and now they're all having to ask themselves whether they're on this time zone or or this one depending on who they are and where they are and there's no way to code that into your program and then then you get a call from the historian who says right i'm trying to calculate some sometimes back in the 18th century and we changed from the julian calendar to the to the gregorian calendar and it's not that we lost about three weeks it's just that we skipped right from this date to this date and and missed the others and can you code it so that so that it just kind of works that out for me and it's fine because someone else has already told you when those dates are and you can code that into your program's logic as well but now it's looking really long and really complicated this tangled mess of spaghetti code that somehow works out and then you get a call from the russian historian who says yeah we only changed the gregorian calendar in the 20th century and it turns out the dates you skip change depend on depending on your location and can you deal with that as well then you get a call from the british historian who says that until i think it was the 16th century the year started on the 25th of march just to blow your mind there on the 24th of march 924 and then it will be the 25th of march 925 and that is the next day because you have gone from december 31st 924 to january the first 924 because it goes in that order and it's massively complicated and then you get the call from the astrophysicist who says by the way we just had a leap second and at this point you just kind of go what leap seconds because the earth does not rotate at a constant speed it slows down it speeds up as as tectonic plates move about and magnetic fields shift or something like that and so occasionally the international astronomical union will work out whether we need a leap second and if you do the clocks go 23 59 58 and then it's 23 59 59 and then instead instead of going like any sensible time zone would it goes 23 59 60 and everything breaks because suddenly you have 61 seconds in a minute so depending on your implementation either your clock gets one second out of sync with the rest of the world or it repeats a second the way you're meant to deal with this is something called the unix timestamp a number file i think has talked about this before that you have this number that started at the first exact second of 1970 and increments one second per second constantly tick tick tick and that's great because what you're meant to do is you take whatever whatever date has been given you and you calculate that as a unix timestamp and you put that into your database and that'll just deal with leap seconds except it doesn't of course it doesn't because because you have universal coordinated time which which includes leap seconds in that it repeats occasionally and it just includes 23 5960 and then you have astronomical time which does not include leap seconds and has steadily been getting out of sync with the rest of the world because we need to look at the stars and design telescopes around it and what you learn what you learn after after dealing with time zones is that what you do is you put away your code you don't try and write anything to deal with this you look at the people who have been there before you you look at the first people the people who have dealt with this before the people who have built the spaghetti code and you go to them and you thank them very much for making it open source and you give them credit and you take what they have made you put it in your program and you never ever look at it again because that way lies madness google actually has a really really good approach to leap seconds that they invented themselves as an article about it on their blog i think that explains it and they do something called a leap smear um because having 61 seconds in a minute or because having a clock tick back a second uh can be really really bad for massive agencies that sort of have to synchronize everything really precisely and have to trust that one bit of data was stored before another they essentially smear the second out over the whole day they increase their clock by a microsecond at a time take all the way through the day so that it's sometimes maybe even half a second out from reality but as long as everything on their servers is half a second out it's built to be out of sync with the world um as long as it knows that one thing happened before another like having continuity is more important than actually having accurate time

Channel: Computerphile

Views: 3,654,854

Keywords: computers, computerphile

Id: -5wpm-gesOY

Length: 10min 12sec (612 seconds)

Published: Mon Dec 30 2013

Reddit Comments

[u/Farkingbrain]

As a programmer you can just tell from the way he tells the story that he has dealt with this stuff before. You can hear the memories of the suffering in his voice.

[u/ibcooley]

I've had to deal with time zones, however not to the extent this guy has. I know (some of) his frustration. Pretty accurate. Even more frustrating is if you are interfacing with another service which gives you a client's local time (timezone offset not given, but adjusted for their timezone) and realize ... fuck.

[u/othilious]

While he touches upon using Unix Time-stamp and says that it doesn't cover the leap-second cases, it has been my experience that using that value is probably the best choice in 99.999% of all cases.

While anyone that has yet to work with them will feel a slight twang of panic due to this video, it's not THAT bad. Let me explain:

You are usually dealing with 3 cases when handling time:

• I want to convert a given date-time value to a centralized (comparable) value.
• I want to convert my value back into the localized value.
• I want to add/substract time (minutes, hours days).

In most programming languages, the easiest, headache-less approach is taking the Unix Time-stamp, and do a date conversion with a location-based timezone (so Asia/Tokyo or Europe/Amsterdam instead of, say, UTC+2) and you get a value that is "good enough" for 99.999% of cases.

Converting back into Unix Time-stamp works the same way; feed a date-time and a timezone and you can get Unix Time-stamp again. Unix Time-stamp is always timezone independent.

This means that 2005-01-01 05:00 in GMT and 06:00 in GMT+1 result in the same Unix Time-stamp.

Which all comes down to his original point. Don't do it yourself. Trust your programming language's implementation if it exists. If it does not exist, grab a package to handle it. In 99.999% of cases, the above is accurate enough.

Which is how you should do the final case; adding and substracting time. Use a language/package "Date" object and tell that to add/substract days/minutes/seconds of whatever it's been set to. You may thing "Oh, I need to add 2 days? I'll just add (3600 * 24 * 2) to the current Unix Stamp". Except that doesn't work when in those days, daylightsavings happens.

So again, for gods sake, use the standard/opensource packages. Both PHP and Java for example make this so ridiculously easy, you really have no excuse.

[u/PublicallyViewable]

He was a good story teller.

[u/mnp]

What's worse than the code is the fact that governments, not content with the havoc and confusion of zones already, need to mess with their daylight savings/standards as well, which are zones. This means that once they do that, everyone needs to scramble to update the calendar in each of their systems, which dictates on which second the local zone will flip from one zone to another. So if you own a computer, you're at the mercy of your govt's political whim, then whoever provides your OS to give or sell you a new version of that table. Good luck with that.

[u/tyzbit]

He should do one about character encodings.

Jesus those are the bane of my existence.

[u/[deleted]]

An open letter to all aspiring programmers: Please store all time values as UTC/GMT or Unix time stamps or equivalent. Do not store them as localized time objects. Do not do math on them as localized time objects. If you display time to the user or receive a time from the user, only then should you convert it to something else using a premade library and whatever their OS spits at you. Convert it before anything else happens, and especially before it gets sent over a network of some kind.

[u/dog_in_the_vent]

How do all of these people keep getting his phone number?

[u/Tonnac]

So having recently read up on how bitcoins work, I've got a semi-related question. In bitcoin verification, it's incredibly important that transactions can be ordered chronologically. Having just touched on how hard it is to keep clocks in sync across the world, what would happen if verifying computers were out of sync?