_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 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.
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."
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"
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
"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
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.
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.
"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.
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.
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.
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.
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.
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 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.
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.
Any chance of getting subtitles for this video, even the RUclips automatic ones? My girlfriend would love to watch and learn, but she's deaf and is having trouble lipreading!
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
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.
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.
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.
I watch this video *at least* two times a years. One time in the spring, one time in the fall, and then again whenever I get bit when calculating time differences.
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.
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.
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.
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.
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!
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.
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?
Before standadised time zones, the time was different in every town. Towns basically had tiny little timezones of their own, based on their perceived position of the sun. They only started to sync up in the latter half of the 19th century, because the railways needed to have consistent time throughout the country to be able to schedule journeys. So you need to know for every place on earth when they started to use standard time rather than local time.
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.
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 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.
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.
This is a brilliant video; one which I occasionally feel the need to return to and watch again. Nearly 11 years out from its initial publication, and I still revisit this rant about time from time to time
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.
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.
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.
By far. Without doubt. The best Computerphile video so far! Great stuff. I've not experienced all of the time / timezone nightmares that Tom spoke about, but, i had enough trouble with times when i coded it that i'd happily change careers if i were ever asked to do it again.
This is one of my favorite RUclips videos of all time. I've shown this to so many people, and even the non-computer people find it fascinating and hilarious. Thank you so much for making this video, and others like it.
i have never cared much for time zones, i have never been in a situation in my life where different time zones has affected me aside from talking to someone on the other side of the world and figuring out when is the best time to contact that person, but this video was presented so well, that it was both informative and entertaining... you just earned a new sub!
This video should be called "Timezones - Tom Scotts descent into madness"
"and THEN...you get a call...from the astrophysicist."
The arrival of an astrophysicist has never been so sinister.
"And you thank them for making it open source" - Best programmer line ever.
And to think, someone just asked Tom what time it was, then started recording.
You forgot when France changed their calendar and tried to introduce decimal time.
You know that your date calculator is accurate when it asks you: "start date, end date, location, ethnicity, political spectrum, belief system"
_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._
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.
And then you get a call from someone on Mars...
I am currently writing timezone code.
EVERY WORD OF THIS IS TRUE.
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."
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"
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.
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.
"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
This was the greatest rant I have ever heard
It was so fun to watch Tom get more and more riled up about all these nuances
"So it was two hours ahead of Greenwich despite having Greenwich" LMAO
It killed me xD xD xD
I can see Tom Scott's hair turn grey, or gray (depending what time zone you're in) during the duration of this video.
Did anyone else just kind of enjoy watching Tom getting progressively more stressed?
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.
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 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.
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.
as a programming student, this made my eye twitch.
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.
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.
"Sooner or later, every programmer has to deal with time zones." Today is that day for me.
This video is a decade old now and is still never not the most painfully relatable thing I've ever watched
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.
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
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 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.
Any chance of getting subtitles for this video, even the RUclips automatic ones?
My girlfriend would love to watch and learn, but she's deaf and is having trouble lipreading!
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
"The year started on the 25th march....just to blow your mind"
Those are the words of a man who has heard everything
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.
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.
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
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.
This is my comfort video; I've watched many many times over the past 5 years
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.
I watch this once or twice a year.
In other words the answer to "What time is it?" is not as straightforward as we think.
I watch this video *at least* two times a years. One time in the spring, one time in the fall, and then again whenever I get bit when calculating time differences.
"Astronomic time is out of sync with the rest of the world."
(Tom Scott)
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.
Let us not forget that is 1752 in September in the UK, we skipped from the 2nd to the 14th
In a few hundred years: coordinating time and date across multiple planets.
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.
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.
Say their names. Arthur David Olson, Paul Eggert. Absolute heroes.
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.
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.
The camerawork makes this so much better
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 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
I love Tom Scott, he is so dedicated to his field
this is by far my favorite computerphile video!
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.
i feel like some of these people are messing with him.
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?
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 keep coming back to this episode... it is absolutely brilliant.
It actually explains any application development, EVER.
Watched this when it first came out, still one of the best Tom Scott rants
and then north Korea calls and says by the way for us its the year 105, have fun
Now suddenly Doctor Who seems less nonsensical. Samoa skips a day? Oh dear.
Before standadised time zones, the time was different in every town. Towns basically had tiny little timezones of their own, based on their perceived position of the sun. They only started to sync up in the latter half of the 19th century, because the railways needed to have consistent time throughout the country to be able to schedule journeys.
So you need to know for every place on earth when they started to use standard time rather than local time.
'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.
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.
I have watched this video so many times since it came out in 2013, and it's still probably my favorite video to ever be uploaded to this platform.
What I learned from this video: Times Zones leads to becoming an Alcoholic.
One is one of the best videos I think he's made.
The thing that bothers me most about timezones is the pronunciation of greenwich
this is one for my favorite videos on youtube. i come back to this every now and then and it never stops blowing my mind
So many years later, I still enjoy happiness in his eyes when he talks about it.
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!
I'm surprised anyone had managed to work this out...they should get a medal,or a knighthood - whatever.
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.
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.
This is a brilliant video; one which I occasionally feel the need to return to and watch again.
Nearly 11 years out from its initial publication, and I still revisit this rant about time from time to time
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.
This gets recommended every year exactly around the daylight savings time end
I am enthralled and want a 20 episode series of this
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.
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.
By far. Without doubt. The best Computerphile video so far! Great stuff.
I've not experienced all of the time / timezone nightmares that Tom spoke about, but, i had enough trouble with times when i coded it that i'd happily change careers if i were ever asked to do it again.
Seemed like a much-needed venting! Love this channel
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.
This is one of my favorite RUclips videos of all time. I've shown this to so many people, and even the non-computer people find it fascinating and hilarious. Thank you so much for making this video, and others like it.
This is still one of my favorite Computerphile videos. They should show this video in every Computer Science course, IMHO.
This is probably why Riley from National Treasure knew exactly when Daylight Savings Time started.
i have never cared much for time zones, i have never been in a situation in my life where different time zones has affected me aside from talking to someone on the other side of the world and figuring out when is the best time to contact that person, but this video was presented so well, that it was both informative and entertaining... you just earned a new sub!
This is the first time I’ve ever felt pity for Tom Scott. Thank you, Mr. Scott for going there before me and giving this warning.
So lucky to see an explanation video by Mr. Paradox about time
Love how this video went from informational to this guy getting really emotional and taking is personally, forgetting he's even in a video