The Problem with Time & Timezones - Computerphile
ฝัง
- เผยแพร่เมื่อ 29 ธ.ค. 2013
- A web app that works out how many seconds ago something happened. How hard can coding that be? Tom Scott explains how time twists and turns like a twisty-turny thing. It's not to be trifled with!
A Universe of Triangles: • A Universe of Triangle...
LZ Compression in Text: • Elegant Compression in...
Characters, Symbols and the Unicode Miracle: • Characters, Symbols an...
More from Tom Scott: / enyay and / tomscott
/ computerphile
/ computer_phile
This video was filmed and edited by Sean Riley.
Computerphile is a sister project to Brady Haran's Numberphile. See the full list of Brady's video projects at: bit.ly/bradychannels
This video should be called "Timezones - Tom Scotts descent into madness"
You know that your date calculator is accurate when it asks you: "start date, end date, location, ethnicity, political spectrum, belief system"
"and THEN...you get a call...from the astrophysicist."
The arrival of an astrophysicist has never been so sinister.
And to think, someone just asked Tom what time it was, then started recording.
"And you thank them for making it open source" - Best programmer line ever.
_Then_ you get a call from a space station in close orbit around a black hole, saying that _their_ seconds are slower than Earth seconds, and ask you to add code to account for _that._
You forgot when France changed their calendar and tried to introduce decimal time.
Don't worry about timezones, worry about why all these people in all those countries know your number :D
Stijn Stevens I laughed out loud to that.
And then you get a call from someone on Mars...
And THEN, you get a call from your boss, asking if you can work tomorrow
You forgot to mention the phone call from a Swedish historian talking about the years from 1700 to 1712, which ended up with February 30 1712 being a real date in Sweden.
I am currently writing timezone code.
EVERY WORD OF THIS IS TRUE.
Just to confuse my students who were tasked to create a simple program to calculate the user's age in seconds, I sent them this video haha.
I like how the Astrophysicist is the breaking point when ironically those are the only people with justifiable reasons for making modifications in time recordings, while the rest of the world's is just like... "We do this, so accommodate us"
Then you get a call from Arizona saying "Oh we don't do Daylight Savings Time."
And then you get a call from the Navajo in Arizona saying "Oh we actually DO do Daylight Savings Time."
This video probably makes a lot of people's blood boils as they sympathize with the pain of being a programmer.
Nice overview, but Computerphile forgot to mention how Sweden in 1699 decided to adopt the Gregorian calendar _gradually_ over a 40-year period - and managed to _butcher the plan_ already the next year. In fact, the period 1699-1753 in Sweden comes with many surprises. For example, Karl XII decided to _switch back_ to the Julian calendar in 1711.
en.wikipedia.org/wiki/Swedish_calendar
"and you never ever look at it again because that way lays madness"
Should be a fun problem to revisit in 2038 when UNIX time breaks.
I can see Tom Scott's hair turn grey, or gray (depending what time zone you're in) during the duration of this video.
It was so fun to watch Tom get more and more riled up about all these nuances
This was the greatest rant I have ever heard
"So it was two hours ahead of Greenwich despite having Greenwich" LMAO
It killed me xD xD xD
Did anyone else just kind of enjoy watching Tom getting progressively more stressed?
"So it was two hours ahead of Greenwich despite ... having Greenwich." (circa 3:55)
And now you know why I prefer to use the term UTC rather than GMT :P
as a programming student, this made my eye twitch.
In other words the answer to "What time is it?" is not as straightforward as we think.
"Sooner or later, every programmer has to deal with time zones." Today is that day for me.
Things were so much simpler when the Earth was flat...
except the fact that the earth would collapse on itself
The days of "local time" when every place had its own time determined by sextant measuring the highest part of the sun's progress across the sky. A nightmare for the railway timetables which is why timezones replaced local time.
Runicartist Didn't quite think of that
aakksshhaayy Maybe...?
coweatsman the funny thing is, if the earth is flat and gravity works like it does. we will fall to the center. rather than falling off the edge
This explains something that's been bugging me for a while, which is that the Enigma Decoding process should have started at 2200 or 2300 British time, if the Germans were changing their code at midnight. And yet everyone portrays it as midnight British time. Turns out that's because the British clocks were 1-2 hours ahead of Greenwhich Mean Time.
Yeah, dealing with time sucks even more than I'd thought it did. And yes, thank goodness for open source software! XD
Wow, you just pointed out a reason why the UK may have wanted to switch to CET during the war.
And then you get a transmitted radio signal from aliens 0.2 light years away from Earth saying that they need the same software produced for their planet.
Also consider, unified timezones are a really NEW concept. Before the industrial revolution and the train, where at best you get to move at the speed of horse, each town, and city had their own timezones. They measured time by their own tow's solar noon. A 20 minute drive from one town to another for us today was much longer in the 17th century. Depending on the terrain and the quality of roads, that trip could be anything from hours and hours of moving at the speed of a trotting horse, if not an entire day's journey.
If Tom's hypothetical program was really accurate, he would also have to go out and find out the SOLAR noon for every city on Earth.
"And then an astronaut on the international space station calls and says that even though they use UTC as their "time zone," since they are traveling at such speed, their clocks run slower, so could you account for that please. And then the 21st century called and ask why everyone is still using telephones to communicate with you."
This was a really good one. Tom's animated way of telling this tale really did draw me in. I thought there might be a library that others have already programmed, but I never thought how terribly complex it could all get.
My mom doesn't know with certainty the day of her birth. That is a bit unusual for Germany, where people take pride in recording everything meticulously. The problem is, she was born in the late 1940ies around midnight-ish, in what was then the Soviet-occupied zone of Germany. And the Soviet government decided that in that year, the way DST works should change, and apparently they made a bit of a mess of it. Historical data disagrees on what time exactly the shift did take place. And even if you could nail down the official time, there would be no way to know whether the midwife's watch would be on the old, or on the new date. Thankfully, astrology seems to be the only field where it causes "actual" problems.
Any chance of getting subtitles for this video, even the TH-cam automatic ones?
My girlfriend would love to watch and learn, but she's deaf and is having trouble lipreading!
"Astronomic time is out of sync with the rest of the world."
(Tom Scott)
Two crucial problems not mentioned for the hypothetical app:
* not all date-times exist in all time zones, e.g. 2013-03-08 02:30:00 does not exist in various USA time zones
* some date-times are ambiguous in some time zones, e.g. 2013-11-03 01:30:00
A particularly annoying case of this is when you want to refer to the beginning of the day: midnight (00:00:00) does not always exist.
Around 8:00 there's an erroneous explanation…
* UTC times are mapped to integers fairly directly, every day has 86400 distinct seconds
* A corollary is that leap second times are 'simply' ambiguous (i.e. the same number refers to two points in time, not one)
* It's usually said that 0 = 1970-01-01 00:00:00 UTC. However, UTC did not exist until 1972, so the times between are not well defined (i.e.
In a few hundred years: coordinating time and date across multiple planets.
Coming back to this video as my country (Lebanon) just decided on a whim that daylight saving is postponed until April 20th this year, so that people may eat earlier for Ramadan
"The year started on the 25th march....just to blow your mind"
Those are the words of a man who has heard everything
Let us not forget that is 1752 in September in the UK, we skipped from the 2nd to the 14th
This is my comfort video; I've watched many many times over the past 5 years
It used to be that each town had its own timezone, such that 12:00 was when the sun was at its apex.
Can’t tell if that’s better or worse than what we ended up with lol.
I keep coming back to this episode... it is absolutely brilliant.
It actually explains any application development, EVER.
I busted out laughing when he brought up the leap second. Wtf?
The leap second in IT is a real bitch. It doesn't appear to be a big deal but it will fuck up everthing if you're not prepared^^.
Yeah, leap seconds are real things. It turns out since we invented really atomic clocks that the we have to adjust our time to keep it in sync with them. According to wikipedia we've had 25 leap seconds since 1972.
Leap days are about keeping the calendar synchronized with certain astronomical events, those being the equinoxes and solstices. Leap seconds are about keeping the clock synchronized with a certain astronomical event. That event being the local solar noon, which is when the sun is on the meridian wherever you happen to be. (Note that local solar noon usually won't be when the clock says 12, but the idea is to keep it from drifting throughout the day.)
You see, as time goes on, the rate of earth's rotation varies. Usually, (always? I'm a programmer, not a geodeticist, however it's spelled) it gets slower, but it gets slower at a rate that varies over time. To account for this without varying the length of the second, they add occasional seconds to particular minutes. These are called leap seconds.
Oh no I totally get it, I just hadn't heard of it before now and the look on his face when he said that was hilarious. I appreciate the explanations, though!
You are not alone, my friend, that was hilarious
Now suddenly Doctor Who seems less nonsensical. Samoa skips a day? Oh dear.
Say their names. Arthur David Olson, Paul Eggert. Absolute heroes.
i feel like some of these people are messing with him.
I rewatch this video once in every half a year, I think, and recommend it to all my friends as it combines very interesting facts with great story pacing.
Absolute ten-minute masterpiece, thank you.
the amount of phone calls this guy gets is absurd
you would expect atleast one of them to have send a text or an email..
amazing video loved it
The camerawork makes this so much better
Soon after an astronaut from the International Space Station phones Tom and says he forgot to set his watch and asks him what time it is in space.
This smear (technically called “slew”) is not unique to Google, actually every Linux system uses that, and not just for leap seconds, ie. for adding seconds but for removing seconds when computer clock gets out of sync as well (as long as the difference is a couple of seconds at most). The main reason is that most programs don't even notice when the clock is a bit slower or faster but experience a lot of problems when clock suddenly changes, even when that change is adding seconds.
This is one of my favorite Computerphile videos. You really begin to feel a programmer's pain...and need for his/her favorite intoxicant of choice! Also, a very interesting insight into time zones, which I never really thought that much about. Entertaining and informative.
As front-end developer (kinda full-stack tho xD) I never thought I was gonna have issues with timezones. But here I am, having issue with server and client being in different time zones and I have to deal with "daily" resets... All of this reminded me of this brilliant video.
Having watched this a second time, and being a former Google senior SWE who dealt with this issue for an internal (non public facing) app, I agree that dealing with time and timezones arguably the most difficult problem. Far exceeding the difficulty of other problems such as facial recognition.
My brain shuts down completely every time I need to deal with timezone issues in building web sites. Even if you deal with all the other stuff that Tom described, get your date inputs encoded as Unix timestamps, and "never look at it again" once in a while you will have to deal at the level of an input of a repeating date and time, such as "Every Wednesday in March and April from 6pm to 8pm" and you must encode it and unpack it very carefully. You can't simply calculate the interval and multiply it out over the course of time, or you end up a second, an hour, or days off.
It turns out very often in making queries you need to refer to something which is as close to the original input as possible, such as "what is the timestamp of the [second] Wednesday in April at 6pm EST?" or "is timestamp X within the specified list of ranges?" So it helps to have a library which can grab the latest data and answer these kinds of requests. Database systems can do timestamp conversions on the fly, but need to be updated frequently to keep up. Then you can store "2012-10-31 12:24:30 PST" and hope for the best, but even this sacrifices some accuracy in cases where the day of the week matters. The smear concept is helpful, and aptly named, the past will all blur together as the internet progresses and reiterates.
I love Tom Scott, he is so dedicated to his field
I'm surprised anyone had managed to work this out...they should get a medal,or a knighthood - whatever.
This gets recommended every year exactly around the daylight savings time end
I'm not sure whether it was made clear why leap seconds are so much worse than daylight saving time. The reason is that everybody only makes the mistake of using local time for anything other than displaying it to the user only once. You use UTC internally and don't give a damn where on the globe you are and what creative way the locals came up with to butcher time.
Astronomers on the other hand mess with UTC itself. They actually make time jump a second in either direction, not just the local _display_ of time. And unless you completely ignore that and keep track somehow of all leap seconds that ever happened and constantly factor them in, you're totally screwed.
What about Ethiopian local time, which starts with 00:00 at 06:00 Ethiopian standard time, because they consider the day to start at sort of generally sunrise and not midnight?
AAAAAND THEN(!) The International Standards Institute in France calls and say, "Oh btw we changed the definition of a second, can you deal with that?"
Not joking, we have changed the reference for seconds from "1⁄31,556,925.9747 of the tropical year for 1900 January 0 at 12 hours ephemeris time", to "the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom" and there is discussion of changing the definition again to something even more precise.
en.wikipedia.org/wiki/Second#Based_on_a_fraction_of_a_year
This very video, which I first watched at release, saved me from a bug yesterday. We had a strange bug where both UK time and CET were apparently on the same timezone. Turns out, the original code formatted the date base only on the number of seconds since the start of the day, since "we don't need to display the date, so that's not needed". Turns out, in January 1970, UK and CET were on the same timezone, and not including the date created this issue. Many thanks to Tom and this video, that lives rend-free in the back of my brain.
Been there, done that. I stored all times as UTC, Gregorian Calendar. Any time older than about 108 years ago was stored in UTC - no time zones. Any time stored older than ~400 years ago was stored as noon (UTC) - to conserve bits and represent relevance. Date/time differences in local events were calculated as accurately as local time zone classes facilitated. Between time zones it went to server, as accurately as most recently provided zone classes could facilitate. Anything over 400 years was just going to provide the difference in days. I lost the contract, threw the manual at the head engineer's head, and became a cook.
Heather Spoonheim So I finished watching the video (made my comment half way through) and I recommend that you also become a cook. Don't make the mistake of opening your own restaurant, however, or you'll end up speaking to your customers as I spoke to mine - because restaurant customers are the only people whom I've met who are less reasonable than engineers.
+Heather Spoonheim There is this thing called Jullian Time, which is used both in astronomy and history/archeology. It starts from January 1, 4713 BC, proleptic Julian calendar. It includes all known written records and thus basically how far back humanity needs to be able to tell dates accurately.
+Heather Spoonheim Yeah, the only thing that can truly save you from this type of black hole is limiting scope and adhering to very strict requirements.
'Leap smear' has got to be one of the most brilliant things I've ever heard of. That is innovative on a whole different level.
I've seen a lot of Computerphile videos but this is one of my favorites. Very funny. I am land surveyor and a few years ago we decided to test standard survey methods to determine location (latitude)against readings provided by a number of different GPS devices ranging in accuracy from 10 meters to 3 cm. Our experiment was to see how accurate stellar observation can be done using 2nd tier survey instruments. Way better than used in early 20th century but still not to the accuracy of top tier instruments. Something that we felt was a standard or a little above of the industry. Anyway the standard formulas all used time zone offsets from Greenwich which we recognized in a very short time how troublesome that can be to determine the time especially when you throw in DST. So we rewrote all the formulas and based our location on a scaled longitude from USGS maps and calculated a time offset from Greenwich. Which in turn let us complete the formula but also provided a means to check our true offset from Greenwich using our computers clock. Then we could utilize the computers clock to reduce our measurements. The point is that you can never be sure what time it really is.
sooo... Tim Scott is going to be the next Doctor, right?
This is a shining example of the sort of nightmares I'm afraid of having as I delve into my computer science program.
I also feel like I want to offer the speaker a strong drink.
I've been a professional computer programmer for, well, it will be 23 years come February. The complexity of dealing with time has to do with the fact that humans have a set of requirements for their time that is not entirely consistent. One of the things that makes those requirements not entirely consistent is the fact that they change over time. Samoa decides that being on the same day as Australia is more important than being on the same day as the rest of the USA, so they change.
Of course, the details are important, but the consequences of getting the details wrong are usually small and, if the consequences are significant, then most people deal with that fact by picking a system based on a nonstandard set of requirements designed specifically to reduce the possibility of the error they're worried about. (I don't know if they still do, but NASA used to use "mission elapsed time" as the official time for their missions to avoid this sort of calendar issue.)
In fact, most of the changes to the time zone file (which is updated about once a month, on average) are about historical times and most people do not care if the results could be an hour off because nobody is sure whether or not Tokyo observed daylight saving time in the summer during the US occupation, just to pick an example that I'm familiar with.
I've always picked stuff like this to work on because I figure that working on this sort of thing was the nearest thing to guaranteed job security. I don't usually work on time issues, but many communications protocols have many of the same issues for many of the same reasons, and it's all very well and good to say "We'll invent Atom to deal with the mess that RSS has become," but it's a much harder thing to get people to adopt it.
the micro nation that I started is 1.234 hours ahead of GMT and it's in the middle of the United States. Try putting that one in.
I vote for Tom to be the new Time Lord. Hell maybe he already is.
Close. Australia actually has 3 different time zones (not including the unofficial Eucla one), which are Western Australia at +8 hours, South Australia and the Northern Territory at +9 1/2 hours and Queensland, New South Wales, the Australian Capital Territory, Victoria and Tasmania at +10 hours.
Now that I've seen the whole video and the research you put into it, I can understand why you made that mistake.
Thanks for the Russian subtitles. This is how I can explain to a Russian historian why my program is so expensive and takes so long to code :)
One is one of the best videos I think he's made.
I have another case to add to different timezones based on who you are and where you live.
For the most part, Ross Island Antarctica (US McMurdo Station and NZ Scott Base) follows NZ time, including DST even though the sun does not rise or set between Oct and Feb and between Apr and Aug (this simplifies flight schedules to/from NZ). This means that depending on the time of year, Ross Island is GMT+12 or GMT+13.
The "home office" for Scott Base is NZ, so no problems there. Most of the activities at McMurdo Station were coordinated through Denver CO (Mountain Time, GMT-6 or GMT-7). This makes it somewhat difficult to schedule meetings between McMurdo and Denver, so the bosses in Denver decided that for one winter, McMurdo would go on Denver time, an 18 hour shift.
What this did was to take a town of a couple hundred people and push them through an 18 hour flip in time from a town that was walking distance away who didn't change their clocks, then a few months later, an 18-hour shift the other way.
It was a disaster and they never did it again.
As an aside, I got involved with working on the Open Source tzlib because when I was at McMurdo in the mid-1990s, my workstation had the wrong time one Summer day. Turns out NZ changed what week they flipped to DST and my OS didn't have an update that knew about the change (a case covered in the video). I dug into how timezones worked in software and ended up making a contribution to the library to tell time more accurately in Antarctica.
So... that bit in the video where you thank the people who wrote that spaghetti code and never look at it again? You're welcome.
The company I work at somehow decided that 1sec = 1024ms in all our product… I can feel the pain.
and then north Korea calls and says by the way for us its the year 105, have fun
I really enjoy that as Tom gets more and more distress, the camera zooms in more and more, and now I too am worried about leap-seconds.
I can't believe I've been coming back to this video for 1/4 of my life. I'll be coming back to this the rest of my life. Or until YT ends, whichever comes first.
Wibbly wobbly timey wimey zones.
Been there. Cried at that.
Cool to be 9 years late to a video but you can thank Arthur David Olson for creating and Paul Eggert, a current professor at UCLA (a quite difficult one at that) for currently maintaining, the tz database which Tom refers to at the end as the open source code that's already done it. Absolute legends.
This is one of my favourite videos on the internet. If any programmer starts talking about writing timezome code they are getting this linked to them from me without exception.
Wow. That's a programmer in a rant. :/
this is by far my favorite computerphile video!
They call them the first, the constructors, the builders. Men who stepped into the very realm of insanity itself, and returned.
And this was the first spaghetti code.
Javamen.
Wow, Tom is a really good explainer on advanced and obscure topics. He should start a TH-cam channel!
Timekeeping is like cryptography: DO NOT ROLL YOUR OWN. Use a well tested, well vetted library, and keep it updated.
After a certain point he sounded like The Doctor going off on a tangent.
Tom Scott = Time Lord
Don't forget that the United States went on "Permanent" Daylight Saving Time from January 6, 1974, to February 23, 1975. Also Arizona doesn't follow Daylight Saving Time but the Reservations in Arizona do and each Indiana county decides if it will go to Daylight Saving Time or not.
Many years after watching it for the first time, here I am: coming back to grab its URL and share with my team who're dealing with timezone issues at this right moment.
I've seen quite a few videos about you explaining maddening phenomenas. And I am starting to see a pattern here... basically... all is fine... until that first time you put in an exception... then the rabbit-hole opens and devours you with arcane and esoteric circumstances. It is almost like walking into a library and in the periphery you notice a book nobody has opened for centuries. It seems harmless enough but when reading it you realize it's the Necronomicon. And you have to beg the elder gods for forgivness. But no... the only way out is insanity.
And I kind of lost track of the direction of this analogy...
AAAAND THEEEN you get a call from Sweden and you're told that in 1712 February had 30 days in their country.
7:20 *tour guide voice* And if you look to your right, you can see Tom Scott going insane over the complications of time zones.
Tom Scott is just so damn enjoyable to listen to.
I genuinely enjoy listening to him talk. Especially when he's teaching stuff.
Computerphile is such a damn good channel!
This is probably why Riley from National Treasure knew exactly when Daylight Savings Time started.
Watched this when it first came out, still one of the best Tom Scott rants
5:55 sounds like the start of a bad joke.
When I first started my IT career, one of the first features that I had to work on was to manage daylight savings and timezones. I was overwhelmed by the complexity.
8:34 you can tell by the sigh that he knows that for experience 😁