_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."
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
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"
"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
Any chance of getting subtitles for this video, even the UA-cam automatic ones? My girlfriend would love to watch and learn, but she's deaf and is having trouble lipreading!
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.
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.
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 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.
"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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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
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'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.
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.
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.
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?
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.
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!
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.
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.
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.
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.
An excellent video which I really enjoyed and the last point you made is perhaps the most profound that continuity is more important than accurate time.
Glad 'Computerphile' exists. In a better world, there would be none of the crap called Daylight Savings Time. Tracking what happened first is quite important and can be very tricky. In addition to being a programmer for over 40 years, I am also an instrument rated pilot. Flight plans are all filed using UTC so they all have the same time reference point.
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.
By the way (I am living in Australia FYI): Australia is split into 3 time zones - Western, Central [Which is GMT+9:30 and where I live (SA)] and Eastern... Until daylight savings when it splits into (I'm not sure of the exact number) about 6 timezones because, for example, on the east coast, one state doesn't want daylight saving because they're farmers and some do want DST and then I just give up on working out time and Google or guess-timate it! :-)
A whole another problem is daylight saving time. I once saw a piece of code that scheduled writing something to a log file always on the next midnight. The programmer, in his great wisdom, had thought that you could do this by adding 24 hours to current time and then checking what day that will be and picking its start. This, of course, is fine on any normal day. When the transition away from DST occurs, however, the clocks are turned one hour back in time at some point of the day. This effectively makes the day last 25 hours, as one specific hour occurs twice: once in DST and once without the DST after the transition. On the midnight on the day of the transition, the program would go 24 hours forwards and check what day it is. Due to the day being longer, this would return the same day. The statistics log update would then be scheduled to the start of the current day rather than the next, resulting in the loop doing the update continuously for a whole hour and gobbling up all the resources.
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...
This video should be called "Timezones - Tom Scotts descent into madness"
"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.
"and THEN...you get a call...from the astrophysicist."
The arrival of an astrophysicist has never been so sinister.
_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 know that your date calculator is accurate when it asks you: "start date, end date, location, ethnicity, political spectrum, belief system"
You forgot when France changed their calendar and tried to introduce decimal time.
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.
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."
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 THEN, you get a call from your boss, asking if you can work tomorrow
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"
And then you get a call from someone on Mars...
"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
I can see Tom Scott's hair turn grey, or gray (depending what time zone you're in) during the duration of this video.
Any chance of getting subtitles for this video, even the UA-cam automatic ones?
My girlfriend would love to watch and learn, but she's deaf and is having trouble lipreading!
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.
"and you never ever look at it again because that way lays madness"
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
Should be a fun problem to revisit in 2038 when UNIX time breaks.
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.
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.
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.
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 video is a decade old now and is still never not the most painfully relatable thing I've ever watched
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.
Did anyone else just kind of enjoy watching Tom getting progressively more stressed?
In other words the answer to "What time is it?" is not as straightforward as we think.
"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.
"So it was two hours ahead of Greenwich despite having Greenwich" LMAO
It killed me xD xD xD
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.
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.
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.
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.
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.
The camerawork makes this so much better
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.
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.
Let us not forget that is 1752 in September in the UK, we skipped from the 2nd to the 14th
Now suddenly Doctor Who seems less nonsensical. Samoa skips a day? Oh dear.
This is my comfort video; I've watched many many times over the past 5 years
i feel like some of these people are messing with him.
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.
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.
"Sooner or later, every programmer has to deal with time zones." Today is that day for me.
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.
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
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.
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
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.
Say their names. Arthur David Olson, Paul Eggert. Absolute heroes.
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.
"The year started on the 25th march....just to blow your mind"
Those are the words of a man who has heard everything
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.
The thing that bothers me most about timezones is the pronunciation of greenwich
and then north Korea calls and says by the way for us its the year 105, have fun
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.
In a few hundred years: coordinating time and date across multiple planets.
So lucky to see an explanation video by Mr. Paradox about 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.
I watch this once or twice a year.
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.
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?
"Astronomic time is out of sync with the rest of the world."
(Tom Scott)
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.
Watched this when it first came out, still one of the best Tom Scott rants
I am enthralled and want a 20 episode series of this
I keep coming back to this episode... it is absolutely brilliant.
It actually explains any application development, EVER.
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
I'm surprised anyone had managed to work this out...they should get a medal,or a knighthood - whatever.
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
this is by far my favorite computerphile video!
'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 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.
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.
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.
I love Tom Scott, he is so dedicated to his field
Wow. That's a programmer in a rant. :/
This is still one of my favorite Computerphile videos. They should show this video in every Computer Science course, IMHO.
So many years later, I still enjoy happiness in his eyes when he talks about it.
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.
One is one of the best videos I think he's made.
Love how this video went from informational to this guy getting really emotional and taking is personally, forgetting he's even in a video
Tom Scott always presents and explains things so well!
Wouldn't it be nice if we could all just work off Unix time somehow?
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.
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.
An excellent video which I really enjoyed and the last point you made is perhaps the most profound that continuity is more important than accurate time.
Glad 'Computerphile' exists. In a better world, there would be none of the crap called Daylight Savings Time. Tracking what happened first is quite important and can be very tricky. In addition to being a programmer for over 40 years, I am also an instrument rated pilot. Flight plans are all filed using UTC so they all have the same time reference point.
and 9 years later i find yet ANOTHER tom scott featuring channel
This gets recommended every year exactly around the daylight savings time end
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.
By the way (I am living in Australia FYI): Australia is split into 3 time zones - Western, Central [Which is GMT+9:30 and where I live (SA)] and Eastern... Until daylight savings when it splits into (I'm not sure of the exact number) about 6 timezones because, for example, on the east coast, one state doesn't want daylight saving because they're farmers and some do want DST and then I just give up on working out time and Google or guess-timate it! :-)
A whole another problem is daylight saving time.
I once saw a piece of code that scheduled writing something to a log file always on the next midnight. The programmer, in his great wisdom, had thought that you could do this by adding 24 hours to current time and then checking what day that will be and picking its start.
This, of course, is fine on any normal day. When the transition away from DST occurs, however, the clocks are turned one hour back in time at some point of the day. This effectively makes the day last 25 hours, as one specific hour occurs twice: once in DST and once without the DST after the transition.
On the midnight on the day of the transition, the program would go 24 hours forwards and check what day it is. Due to the day being longer, this would return the same day. The statistics log update would then be scheduled to the start of the current day rather than the next, resulting in the loop doing the update continuously for a whole hour and gobbling up all the resources.
After all this time, still one of my favorite videos
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...