The Complexity of Timekeeping: A Historian's Nightmare

When it comes to timekeeping, most people think of simple things like setting their clocks to the right time zone and following the usual flow of days. But for historians, this is just the tip of the iceberg. With a mere change in calendar from the Julian to the Gregorian calendar, problems arise when trying to calculate dates back in the 18th century. It's not that we lost about three weeks, but rather we skipped over those dates and missed them entirely. This can be frustrating for historians who are trying to make sense of past events.

But it gets even more complicated when dealing with different countries and their own unique timekeeping systems. Take the Russian historian, for example, who calls in to say that they only changed to the Gregorian calendar in the 20th century. This means that dates skipped depend on location, adding another layer of complexity to an already tangled mess of spaghetti code. And if that's not enough, there are also issues with starting dates, which can be as simple as the year beginning on March 25th rather than January 1st.

The Problem of Leap Seconds

One of the most vexing problems in timekeeping is the issue of leap seconds. The Earth does not rotate at a constant speed, slowing down and speeding up as tectonic plates move about and magnetic fields shift. This means that the International Astronomical Union has to work out whether or not we need a leap second every so often. If they decide to add one, the clocks will go from 23:59:58 to 23:59:59, but if they don't, things can get messy. The problem arises when trying to implement this in programming languages, where there's no easy way to code for time zone changes or leap seconds.

That's why developers often turn to pre-existing solutions and libraries that have already dealt with these issues. But sometimes, even the most experienced programmers get overwhelmed by the complexity of timekeeping. This is where they turn to the community, looking at what other people have done before them and taking their code as a starting point.

The Unix Time Stamp: A Solution

One approach to dealing with leap seconds is the Unix time stamp, which starts at the first exact second of 1970 and increments by one second per second. This approach may seem simple, but it's actually quite elegant. By calculating a date as a Unix time stamp and storing that in a database, you can avoid most of the problems associated with leap seconds. However, this system is not foolproof, and there are still issues to deal with.

The Smear: A Solution for Leap Seconds

Google has developed an approach called a "leap smear," which involves spreading out the second over the day rather than all at once. This can help prevent massive agencies from getting their clocks completely out of sync with each other. By increasing the clock by a tiny amount every few seconds, they're able to maintain continuity and accuracy even when dealing with leap seconds.

However, this approach also has its own set of problems. If everything on an agency's servers is only half a second off from reality, it can still cause issues when trying to synchronize data. The key is finding a balance between accuracy and continuity, rather than striving for absolute precision.

In conclusion, timekeeping is a complex issue that requires careful consideration and planning. From calendar changes to leap seconds, there are many factors to take into account when trying to keep accurate records of the past. While it may seem simple at first glance, dealing with these issues can be overwhelming – but by turning to pre-existing solutions and libraries, developers can focus on other aspects of their work rather than getting bogged down in the intricacies of timekeeping.

"WEBVTTKind: captionsLanguage: ensooner or later every programmer has to deal with time zones and I can't really offer much advice here I can offer a cautionary tale um I can tell you why you really should never ever deal with time zones if you can help it let's imagine that someone has has built an application that lets you calculate how many seconds something is in the past you type in a date and a time it gives you the number of seconds and they they look at that and think okay that that kind of works for me but let's let's add a little box that lets you change the time zone so if you're you know if you're comparing between now in New York and 5 days ago in London you can work that out and that's fine you know the little drop down lets you change which hour forward or backward of Greenwich you are brilliant sooner or later after it gets a bit popular they'll get a call from Australia and Australia will say good day I'm not going to try and do accents um austr I just shouldn't do accents um Australia will say hello um by the way we're 9 and 1 half hours ahead of Greenwich and the program will go really I like yeah yeah 9 and a half hours oh okay I'll add a special case for you that's fine then a little bit later someone will call from Napal and they'll say hello um we're 5 and A4 hours ahead of grenic and they'll say really I say yeah yeah we've been that for ages yeah 5 and a/ qu hours Great okay and they'll and put in a special case and maybe they'll look up the list of time zones the the canonical list that tells you what everything is they'll make sure they covered every time zone in the world and then Autumn will come along and we'll get a call from England and uh England will say excuse me um we're an hour out at the minute what's going on and the work hold on the clock's just changed that's fine no no we dealt with that we dealt with we we made a note of when Daylight Saving changes for us and we've put that in and and England will say no see Daylight Saving changes a week earlier for us it's different depending on where you live we we shift our clocks back a week before you do and and at that point that point generally the program will start to hold their head in their hands and realize what they've got themselves into and that's fine you know they they'll put that in and they will deal with each country shifting to Daylight Savings Time on a different day and they'll look at the file that tells them how to do that and they'll copy all that in and then they'll get a call from someone in the southern h atere again who will say yeah we're not shifting back in the Autumn we shift forward our our spring is in November and and that point they'll generally start looking longingly at their intoxicant of choice and wondering whether they should have a quick drink before keeping going and and then they'll they'll code that in as well and then they'll get a call from Samoa out in the Pacific on the international dat line and Sor will say hello um yeah we we skipped today the other year and the program will say what say yeah we skipped today we went from December the 29th 2011 to December the 31st we we shifted from one side of the International Date Line from being hours and hours behind grenic to being hours and hours ahead of Greenwich helps us with trading with Australia can can you take account of that when you work out how many days things are and how many seconds things are in the past it's fine there's a there's a file that tells you when any country has changed its time zone and it turns out that that happens fairly often but they they're announced ahead of schedule so as long as you keep that file updated and code that into your program's logic as well it'll be fine then you look back and you notice that during World War II England had double British summertime it went completely onto BST and then just added an extra hour so it was 2 hours ahead of Greenwich despite having Greenwich that's fine you deal with that it's changing if you notice I'm starting talking as if as if it was you or me because I've done this before and it's really really frustrating and you make sure that you subscribe to the list of when countries are going to change their time zones which happens apparently many times like sometimes several times in a year because governments change over and then then the program this this mythical programmer gets a call from Libya who in 2013 with only a couple of days notice decided that they weren't going to put the clocks back with enough notice said it wasn't possible for anyone to get the update out in time and meaning that every Libyan computer no matter what operating system it ran was an hour out if it's okay you you read the news article about that and you hurriedly code that in as well and then then you get a call from the West Bank where the Israeli population is on a different time zone to the Palestinian population because one is following Israel and one isn't and now you have two populations of people in the same location who are following different time zones and now they're all having to ask themselves whether they're on this time zone or or this one depending on who they are and where they are and there's no way to code that into your program and then then you get a call from the historian who says right I'm trying to calculate some some times back in the 18th century and we changed from the Julian calendar to the to the Gregorian calendar and it's not that we lost about three weeks it's just that we skipped right from this date to this date and and missed the others and can you code it so that so that it just kind of works that out for me and it's fine because someone else has already told you when those dates are and and you can code that into your program's logic as well but now it's looking really long and really complicated it's Tangled mess of spaghetti code that somehow Works down and then you get a call from the Russian historian who says yeah we only changed the Gregorian calendar in the 20th century and it turns out the dates that you skip change depend on depending on your location and and can you deal with that as well then you get a call from the British historian who says that until I think it was the 16th century the year started on the 25th of March just to blow your mind there on the 24th of March 924 and then it will be the 25th of March 92 5 and that is the next day because you have gone from December 31st 924 to January the 1st 924 because it goes in that order and it's massively complicated and then you get the call from the astrophysicist Who Says by the way we just had a leap second and at this point you just kind of go what leap seconds because the Earth does not rotate at a constant speed it slows down it speeds up as as tectonic plates move about and and magnetic fields shift or something like that and so occasionally the international astronomical Union will work out whether we need a leap second and if you do the clocks go 23 59 58 and then it's 23 59 59 and then instead instead of going like any sensible time zone wood it goes 23 59 60 and everything breaks because suddenly you have 61 seconds in a minute so depending on your implementation either your clock gets 1 second out of sync with the rest of the world or it repeats a second the way you're meant to deal with this is something called the Unix time stamp a number file I think has talked about this before that that you have this number that started at the first exact second of 1970 and increments 1 second per second constantly tick tick tick and that's great because what you're meant to do is you take whatever whatever date has been given you and you calculate that as a Unix time stamp and you put that into your database and and that'll just deal with leap seconds except it doesn't of course it doesn't because because you have Universal Coordinated Time which which includes leap seconds and that it repeats occasionally and it just includes 2359 60 and then you have astronomical time which does not include leap seconds and has steadily been getting out of sink with the rest of the world because we need to look at the stars and design telescopes around it and what you learn what you learn after after dealing with time zones is that what you do is you put away your code you don't try and write anything to deal with this you look at the people who have been there before you you look at the first people the people who have dealt with this before the people who have built the spaghetti code and you go to them and you thank them very much for from making it open source and you give them credit and you take what they have made and you put it in your program and you never ever look at it again because that way lies Madness Google actually has a really really good approach to LEAP seconds that they invented themselves there's an article about it on on their blog I think that that explains it and they do something called a leap smear um because having 61 seconds in a minute or because having a clock tick back a second uh can be really really bad for for massive agencies that sort of have to synchronize everything really precisely and have to trust uh that one bit of data was stored before another they essentially smear the second out over the whole day they increase their clock by a microsc at a time tick tick tick tick tick all the way through the day so that it's sometimes maybe even half a second out from reality but as long as everything on their servers is half a second it's built to be out of sync with the world um as long as it knows that one thing happened before another like having continuity is more important than actually having accurate timesooner or later every programmer has to deal with time zones and I can't really offer much advice here I can offer a cautionary tale um I can tell you why you really should never ever deal with time zones if you can help it let's imagine that someone has has built an application that lets you calculate how many seconds something is in the past you type in a date and a time it gives you the number of seconds and they they look at that and think okay that that kind of works for me but let's let's add a little box that lets you change the time zone so if you're you know if you're comparing between now in New York and 5 days ago in London you can work that out and that's fine you know the little drop down lets you change which hour forward or backward of Greenwich you are brilliant sooner or later after it gets a bit popular they'll get a call from Australia and Australia will say good day I'm not going to try and do accents um austr I just shouldn't do accents um Australia will say hello um by the way we're 9 and 1 half hours ahead of Greenwich and the program will go really I like yeah yeah 9 and a half hours oh okay I'll add a special case for you that's fine then a little bit later someone will call from Napal and they'll say hello um we're 5 and A4 hours ahead of grenic and they'll say really I say yeah yeah we've been that for ages yeah 5 and a/ qu hours Great okay and they'll and put in a special case and maybe they'll look up the list of time zones the the canonical list that tells you what everything is they'll make sure they covered every time zone in the world and then Autumn will come along and we'll get a call from England and uh England will say excuse me um we're an hour out at the minute what's going on and the work hold on the clock's just changed that's fine no no we dealt with that we dealt with we we made a note of when Daylight Saving changes for us and we've put that in and and England will say no see Daylight Saving changes a week earlier for us it's different depending on where you live we we shift our clocks back a week before you do and and at that point that point generally the program will start to hold their head in their hands and realize what they've got themselves into and that's fine you know they they'll put that in and they will deal with each country shifting to Daylight Savings Time on a different day and they'll look at the file that tells them how to do that and they'll copy all that in and then they'll get a call from someone in the southern h atere again who will say yeah we're not shifting back in the Autumn we shift forward our our spring is in November and and that point they'll generally start looking longingly at their intoxicant of choice and wondering whether they should have a quick drink before keeping going and and then they'll they'll code that in as well and then they'll get a call from Samoa out in the Pacific on the international dat line and Sor will say hello um yeah we we skipped today the other year and the program will say what say yeah we skipped today we went from December the 29th 2011 to December the 31st we we shifted from one side of the International Date Line from being hours and hours behind grenic to being hours and hours ahead of Greenwich helps us with trading with Australia can can you take account of that when you work out how many days things are and how many seconds things are in the past it's fine there's a there's a file that tells you when any country has changed its time zone and it turns out that that happens fairly often but they they're announced ahead of schedule so as long as you keep that file updated and code that into your program's logic as well it'll be fine then you look back and you notice that during World War II England had double British summertime it went completely onto BST and then just added an extra hour so it was 2 hours ahead of Greenwich despite having Greenwich that's fine you deal with that it's changing if you notice I'm starting talking as if as if it was you or me because I've done this before and it's really really frustrating and you make sure that you subscribe to the list of when countries are going to change their time zones which happens apparently many times like sometimes several times in a year because governments change over and then then the program this this mythical programmer gets a call from Libya who in 2013 with only a couple of days notice decided that they weren't going to put the clocks back with enough notice said it wasn't possible for anyone to get the update out in time and meaning that every Libyan computer no matter what operating system it ran was an hour out if it's okay you you read the news article about that and you hurriedly code that in as well and then then you get a call from the West Bank where the Israeli population is on a different time zone to the Palestinian population because one is following Israel and one isn't and now you have two populations of people in the same location who are following different time zones and now they're all having to ask themselves whether they're on this time zone or or this one depending on who they are and where they are and there's no way to code that into your program and then then you get a call from the historian who says right I'm trying to calculate some some times back in the 18th century and we changed from the Julian calendar to the to the Gregorian calendar and it's not that we lost about three weeks it's just that we skipped right from this date to this date and and missed the others and can you code it so that so that it just kind of works that out for me and it's fine because someone else has already told you when those dates are and and you can code that into your program's logic as well but now it's looking really long and really complicated it's Tangled mess of spaghetti code that somehow Works down and then you get a call from the Russian historian who says yeah we only changed the Gregorian calendar in the 20th century and it turns out the dates that you skip change depend on depending on your location and and can you deal with that as well then you get a call from the British historian who says that until I think it was the 16th century the year started on the 25th of March just to blow your mind there on the 24th of March 924 and then it will be the 25th of March 92 5 and that is the next day because you have gone from December 31st 924 to January the 1st 924 because it goes in that order and it's massively complicated and then you get the call from the astrophysicist Who Says by the way we just had a leap second and at this point you just kind of go what leap seconds because the Earth does not rotate at a constant speed it slows down it speeds up as as tectonic plates move about and and magnetic fields shift or something like that and so occasionally the international astronomical Union will work out whether we need a leap second and if you do the clocks go 23 59 58 and then it's 23 59 59 and then instead instead of going like any sensible time zone wood it goes 23 59 60 and everything breaks because suddenly you have 61 seconds in a minute so depending on your implementation either your clock gets 1 second out of sync with the rest of the world or it repeats a second the way you're meant to deal with this is something called the Unix time stamp a number file I think has talked about this before that that you have this number that started at the first exact second of 1970 and increments 1 second per second constantly tick tick tick and that's great because what you're meant to do is you take whatever whatever date has been given you and you calculate that as a Unix time stamp and you put that into your database and and that'll just deal with leap seconds except it doesn't of course it doesn't because because you have Universal Coordinated Time which which includes leap seconds and that it repeats occasionally and it just includes 2359 60 and then you have astronomical time which does not include leap seconds and has steadily been getting out of sink with the rest of the world because we need to look at the stars and design telescopes around it and what you learn what you learn after after dealing with time zones is that what you do is you put away your code you don't try and write anything to deal with this you look at the people who have been there before you you look at the first people the people who have dealt with this before the people who have built the spaghetti code and you go to them and you thank them very much for from making it open source and you give them credit and you take what they have made and you put it in your program and you never ever look at it again because that way lies Madness Google actually has a really really good approach to LEAP seconds that they invented themselves there's an article about it on on their blog I think that that explains it and they do something called a leap smear um because having 61 seconds in a minute or because having a clock tick back a second uh can be really really bad for for massive agencies that sort of have to synchronize everything really precisely and have to trust uh that one bit of data was stored before another they essentially smear the second out over the whole day they increase their clock by a microsc at a time tick tick tick tick tick all the way through the day so that it's sometimes maybe even half a second out from reality but as long as everything on their servers is half a second it's built to be out of sync with the world um as long as it knows that one thing happened before another like having continuity is more important than actually having accurate time\n"