 On to the main reason we're all here. I'd like to introduce you to John Diel, who's going to be talking to us about leap seconds. So let's all welcome John. We're going to approach today. We're going to be talking about leap seconds. Sorry. Is my audio OK? Yeah, OK. So we're going to be talking about leap seconds. When I talk about leap seconds, the people, I get kind of one of these reactions. On the whole, nobody cares. Most of your average person is probably never even heard of it. But what we find is, if you're working with computers, it's one of these things that comes up again and again and again. Front-end programmers really don't care what color do you want it. They're not interested. Back-end engineers, they've always got a horror story of some kind. But it's the network engineers that really feel it. They're the ones that are booking holiday in June and December, because they don't want to be around. Cloud DevOps has kind of gone a little bit different now. They've got their smearing thing, so they're happy. They're cool. The astronomers are hands off my leap second. Quite beaming about that. So I'm going to explain. This is what I'm hoping to get through today. So I'm going to define exactly what a leap second is. So if there's anybody in the room who's not familiar with it, at least we'll have some frame of reference for what we're talking about. And then we're going to try and get into the weeds of why we have these things. And actually, why do we put ourselves through this sometimes? Because there's some competing reasons for why you would want to have this thing. And then we'll go into how it gets propagated, how it gets out to all of the systems that it connects to or it's used in. And then we'll look at some of the problems and how we solve some of those problems. So let's try and have a basic definition of what a leap second is. So if you've never come across it, it is a one-second adjustment to the clock on your computer. It sounds fairly trivial. It sounds fairly simple. It turns out, in practice, that's less often the case. So here's an example of what one would look like. So your clock inside your computer is ticking away. And it has 60 seconds in a minute, which you would expect. So that will go from 0 to 59. And then round again to 0 to 59. In the case of a leap second, you have a 60. So you will have 61 seconds in your minute. So you'll see here on the right-hand side, the red one. And that's your leap second going in. It's entirely possible you could have a negative leap second. We've never had one. But in practice, they would look like that. So it would get to 58. It would skip. And then it would go to 0. So we've had about 27 of these over the course of the last 30-odd years. Well, probably longer than that, the 40-odd years. Since 1972, and the last one was a couple of years ago, they tend to happen at the end of June and at the end of December. But they can actually happen at any month. But they're trying to keep them relatively spaced apart. But the spec allows for them to be at any month. So we have trouble with them. I mean, almost every time we come around, there's some problems. And this was in, I think, three leap seconds ago, we had this. And Linus was saying, yeah, we always find something. There's so many different inter-competing systems that we come across. So I'll try to pull a few examples together. So this was the 2008 leap second. Oracle and Sun had some issues. In 2012, this was a big one. It got hit a lot of news sites. But that was Java and Red Hat had some issues just processing the leap second. In 2015, it was Twitter and Android. And you can find examples of this all the way through. The most recent one was Cloudflare DNS. It was some of the problems with the Go language couldn't process it, particularly so. So we have problems with them. So we have to think, why do we put ourselves through this? Why do we actually want this leap second to be in there? So let's look at why we actually want them. So the way to approach this is really to look at how we measure time. Because we have two competing ways of measuring time. The way we have measured it for years and years and years, all the calendar systems and the hunter's gatherers would have looked at the sun going across the sky. And the day-night cycle is how you would imagine your day is. But it's the observable day, as I would put it. So it's what you can see in the sky. So that's what most people's definition of a day is, actually. You can do this yourself. It's one of the simplest experiments in the world. You put a stick in the ground. You need a flat surface. And as the sun tracks across the sky, it casts a shadow. And this particular one I took in Blackheath. So this is very almost Greenwich meantime. But somebody's painted it on the ground as it's gone around the bollard. But we have way better ways of tracking it than my bollard. We have the International Earth Rotation and Reference System Service. And their job, really, is to track what the earth is doing in the sky. And they use that by tracking things like quasars or very, very far away astronomical phenomena. And they can tell from how quickly this goes around what the actual rotation of the earth is, as opposed to what it should be or what you would imagine it to be. They produce three timescales in the back of that. For our purposes, UT1 is the one we're going to look at today. So the other way you can measure time or more recently, since the 1950s, we've had atomic clocks. And atomic clocks are measuring frequency of cesium atoms, essentially. We've got something that you can have a clock here in EMF, or you could have a clock in the International Space Station, or you could have a clock in Australia. And you're all measuring the same phenomena. So you will get the same frequency standard. So there's a few pictures of atomic clocks. These are from NPL. So the earliest ones there are the 1950s at the top. Still very accurate, but we've got more and more accurate as the years have gone by. If I bumped into a chap, I was putting my tent away just about 10 minutes ago. And he worked at NPL, and he was telling me that there's an even better clock on the way as strontium standard, which was interesting. So that's classic EMF. Atomic time is put together by the International Bureau of Weights and Measures. So they look after the SI second. They actually look after all of the SI units. They're based in Paris. And in terms of timekeeping, they look after three timescales. They look after EAL, TAI, and UTC. And we'll get into those in a second. But if you compare atomic time with universal time, it becomes really clear that the Earth isn't terribly accurate. It wobbles around quite a lot. And it has cycles that it goes through as well. But for precise timekeeping, which is something you need for computing, the Earth is no longer useful to us in that respect. It is useful depending on what you're looking at. If you're an astronomer, you want to know exactly where the Earth is. Or if you're working in mapping or things like that, you'll definitely want to know those. But you have competing standards of what the definition of the day is. Those two things are being pulled apart. So this became a problem in the 1970s. And then we standardized on a global time scale for the Earth. And that's universal coordinated time. So it's the time standard that we use for communicating or for making sure that the time that we have here is also the time in Australia. It's the time all around the world. So UTC time is the same everywhere. And it's a bit of compromise between those two time skills that we were talking about. So it's an atomic time scale. But it has what they call discontinuities. And those discontinuities are leap seconds. So what we try and do with UTC is keep UTC close to what the Earth is doing. So it's an atomic time scale. It's still measuring SI seconds. But it keeps to what the Earth is doing by having these leap seconds inserted into it to steer it close to what UTC 1 is. So here's an example of all the leap seconds when they've been applied. So they see that it's not a regular thing. Leap seconds come when you need them. And they're done in order to have an atomic time scale but still allow us to have it tie up with what you see in the sky. And so the way this works is the people we spoke about on the International Earth Rotation Reference Service, IURS, they are looking at UTC as well. And when they see that it's differing by about 0.6 of a second, then they'll apply a leap second. Leap second, you normally get about six months advance warning on. And it's announced in this IURS bulletin C. So that's leap seconds. That's why we need them because we're trying to keep the Earth in the Earth rotation in line with our timekeeping system. So how do you make one? Again, it's co-coordinated time. That's quite well-named because it's a coordinated effort. There's an awful lot of bodies involved in order to make it work. It's actually a telecom spec. UTC is defined by the International Telecoms Union. And they debate it very, very often about whether they're going to continue with this. It's actually produced. The leg work is done in Paris by the BIPM. So they, well, I'll get into that in a second. But then the leap seconds are coming from the IURS. So you have three bodies really involved in this thing. But how it's actually done day to day, there are 70 measurement labs around the world in very different places. But what they're doing is those labs have atomic clocks in them. And the information from those atomic clocks are sent to Paris. And they're pulled together. Excuse me. Actually, I'll go into firstly. The UK one is in Teddington, NPL. So Teddington produced a Rural Time Scale. So the UK National Time Scale will be UTC, brackets, NPL. And that's the UK's realization of UTC. They have commercial atomic clocks. But they also have things like this. This is the primary frequency standard. This is very, very, very accurate clock. And this is for tracking what the SI second is or trying to get as close to the SI second as you can. So it's important to make the definition between atomic clocks, commercial atomic clocks, as you may have seen. Those are not as accurate as this kind of thing. But all of the atomic clocks in all of the labs around the world send their data to Paris. Paris crunch the data and produce free atomic time. So free atomic time is the first time scale. But it's not really used. The next step in the process is to create international atomic time. And the way that they do that is they use the primary frequency standards to steer all of those clocks closer to what the SI second actually is. So that's the kind of massaging process over the top of that. And from that, you get international atomic time. And once you have that one, then you can apply the leap seconds you've got from the International Earth Rotation and Reference Service. And voila, you have UTC. That's how the sausage got made. And those get announced monthly. All of that processing is pulled in. And monthly, they publish the BIPM circular T, which is essentially a big long list of what UTC is versus the offsets from all of the different labs all around the world. So let's go back to the labs. And the labs actually use that as a course correction for them to get their clocks back into line with what UTC is. So maybe not obvious if you've come across UTC. You may assume it's just all mapped up in advance. But it's actually being laid down in arrears. It's not a real-time thing. And this is quite surprising, because this is the standard for all timekeeping on Earth. And it's not, you can't project ahead. It's all being laid down behind us. The closest you can get to a real-time representation of UTC is to actually go to your local lab. So in our case, it would be NPL. You would go to them. They have an NTP server. And they will give you UTC back. So that's our local realization of it. I'm only looking at that in there for the slides. So if you come at this later, this might make some kind of sense. But that's the system for how you actually get UTC in leap seconds. OK, so now we've got them. How do we get them out to the world? So all of the computers in the world, all of the systems in the world, for the most part, are running some version of UTC. So you've got radios were used originally. I don't have an awful lot of information on the radio. So I didn't really get into that. But most commonly these days, it would be something like GPS or over the internet with NTP. GPS broadcasts. GPS has its own timing system. But it has offsets from UTC. And those are picked up by base stations. And then that's how UTC has been propagated over those systems. And then NTP usually will be, well, there's any number of ways you can get NTP hooked up to something. But you need some kind of standard where you know what UTC is. And then NTP is sent over the wire. And it syncs with your computer. So there's a couple of flags in NTP that tell you if the leap second is coming. NTP can be a bit wobbly because there's lots of implementations of it. But precision time protocol, I quite like this. This is an atomic time scale. So it keeps, basically, tracks atomic time. But it has offsets to UTC. So it doesn't have any leap seconds. It just keeps the offsets up today. So we're going to some of the problems. I mean, if you think about what's actually happening here, UTC being a global time scale is all of the computers in the world are updating at the same time. And that's got to be a headache. It's definitely, that's going to cause some problems. Also, future leap seconds are unpredictable because you don't know what the Earth is going to be doing. The Earth is going to do what the Earth does. So you'll get a leap second when you get a leap second. So there's no way to programmatically put that up to work that out in advance. And that's obviously another problem that comes with them. So they have inherent problems that computers do not like. So, but you cannot, the Earth does what the Earth does. So it's the same with daylight saving time. That's much more of a tire fire, but we'll get into that another day. But leap seconds can be positive or negative. Again, we've not had negative ones. If we ever have a negative one, then, you know, go find, come here, or do not actually, go with someone with no technology. Just go hide because it's going to be bad. And the other one is the POSIX problem. So I'll get into this. We have two rep. When we talk about UTC, we really should define it a little bit tighter. It's, in terms of the specification, what UTC has defined as for the telecom spec, it has leap seconds. But the two standards, the standard for Unix, POSIX standard, was being developed around the same kind of time as the UTC standard. And they took different approaches on how they would manage it. The POSIX and Unix talk about UTC, but they don't implement leap seconds in terms of their timekeeping. The way Unix works is it has a counter from 1970 and it's count seconds. But there's no realization of what leap seconds are. So that causes some problems. Just to give you an example of how that looks. So atomic time is on the left there. So you can see atomic time ticking away as it does. It doesn't have leap seconds. It just happily takes 29, 30, 31. UTC does have leap seconds, but it pops a 60 in there for that 60 second, 60 for a second. But Unix actually represents that as a single number defining two seconds out. So that's a problem. Bugs can come out of that kind of thing. So let's look at some of the common strategies we have for dealing with these things. So this is the, if you're, not all versions of Unix and Unix are POSIX compliant, they, people have other implementations of it, but the ones that are, they step the clock back. So you've got, essentially the clock goes forward and it'll play out the leap second and then at the back it steps it back by one second. NTP does it slightly differently. It just stops the clock. So the clock stops for one second and it moves on again. So it doesn't go backwards. And this has become quite popular recently. This is leap smearing. So Google tried this, I believe, originally. There has been different sort of experiments done by different cloud providers. But more recently, or in the last one, certainly, they're standardizing on this 24 hour leap smear. So the idea of a leap smear is over the course of 24 hours you put that second in but you change the clock. So you're no longer getting SI seconds, you're getting something slightly off. But it sneaks that second in over the course of a 24 hour period. And then you have, your clocks never get the leap second. They just, every now and every time they catch up with NTP, then they're getting slightly slewed version of the time. But then you'll never get that leap second because you never have the problems of dealing with leap seconds. And it really only works on anything that's got a sort of, like the internet, it's a bit laggy sometimes and you can get away with this kind of thing. But it's a good approach for this, but it's got, I really are not happy that it's not giving me SI seconds, I want SI seconds. You can avoid leap seconds. I mean, I think that's a really sensible approach sometimes. It depends on what you're actually trying to do and what you need time for. If you wanted to use something like atomic time, I think atomic time's really sensible. It's been ticking away since the 1950s. You just one second each time. And if you never have to deal with leap seconds, that's great. A lot of problems just disappear. But you will need some way of getting UTC time back very often. You can ignore it, that's what Windows does. Windows is meh, you know, whatever. What happens with Windows essentially is that you get to midnight or whenever the leap second is coming in and it just doesn't do anything and it waits for NTP to catch up. So NTP is syncing to a server looking for the time and saying, oh, the time is off now. But it will do it whenever it decides to do it. So you'll find that it can be off by a couple of minutes. It can be off by even longer. It depends really what this, how often NTP decides to check up. It works, it's just annoying. Everything's out of sync for a little while. You can abolish it. I mean, that's what this has been talked about since the 1999. Some countries are for it. Some countries are against it. And it really depends on who's lobbying and for the most part, astronomers have other ways of doing this, but they want to keep it really. You'll find that some countries jump back and forward and divide depending on what's going on. But we still haven't got to a point where we can say this is definitely going away. It's still around for now and it's about to be debated again in 2023. But it keeps being put off. Or you can actually implement it, which is this was very annoying. Microsoft have actually gone and done it right. So we've got our situation where I'm told that the latest version of Windows Server will actually have full support for in leap seconds. It will actually have very precision timekeeping. So yeah, if you have very, very tight timekeeping needs, this is probably gonna do it for you. So in summary, I would say pick the time scale that matches your use case because if you're looking for accurate what the earth is doing, you should be looking at UT1 and you can actually get UT1 over NTP. NIST give you that. So if you care about what the earth is doing, go that route. If you want precision timekeeping, like precision frequency, then you should be looking at something like TAI or atomic time if you want something in the middle or if you want to be talking to other people, UTC is the standard. You need to look for something in the middle, so. That would be me, yeah. There we go. Yes, questions, that's exactly what we're on to. Questions, but just please wait for the microphone so we can all hear you. You mentioned UT1. What are UT0 and UT2? Yeah, so UT0 is the raw data, if you like. What UT1 is, is they apply some, there's some polar motion that comes with it, there's regular polar motion. What UT1 is filters out the polar motion. UT2 actually filters out a whole bunch of other stuff, but UT1 is the one that is primarily used for its comparison, yeah. You can't get those things, but nobody tends to use them, yeah. If it's 2023 and leap seconds get abolished, will the updates, will the bulletin C, will it still be produced, and there'll just be a timescale called UTC still with leap seconds in it that nobody uses? I think what will happen is UTC will sort of freeze. So it'll still exist as a timescale, it'll still be offset from atomic time by 37 seconds at that point, unless they've put any more in. But then it'll begin to drift from what the Earth is doing. So UTC will just kind of get locked in time actually. Yeah, sorry, the question was more, would they still, would somebody keep doing leap seconds, like, because they really love them? I actually, if you look to the, if Paris wants rid of it, France wants rid of it, and mainly because of the overhead of producing it, you can imagine how much work, and people, you know, there's a huge amount in actually making this thing work. So yeah, I think it would get frozen in time, and in fact, you don't need to produce it at that point. So if you decide that you don't need leap seconds, you can just lock it from atomic time going here and offset it by 37 seconds. You're still tracking atomic time. So somebody somewhere is gonna have to do all of that, but you don't have the leap second part, so. Yeah, I think you still need atomic time. You still need to synchronize all of those clocks to get some representation of, so I think, yeah, Paris is stuck with it, yeah. You mentioned that you get a little bit of advanced notice up to six months. How well do we actually, are we able to predict these things? I mean, if you wanted more than six months notice, would that be feasible? I mean, how well are the differences? No. I mean, you will get, if you, there's a mailing list, you can get it, and you know it's coming, and what generally happens is, that's the first people who get it are the time, the labs who are getting all of this information, so they then put UTC together, and UTC is a monthly thing, so very often, you'll know six months beforehand, or about six months, just less than six months, so anybody who is caring about that can get that stuff into their systems early, because if it's just a lookup table, that's really easy, I think that's very generous, actually, to be able to get, if you can't put an update out with six months notice, then you're not doing it right, so. It's a slightly frivolous question, but when we have leap years, when we have leap years, what happens is, they introduce an extra day in February, so why are leap seconds not called leap hours? I did think of the worst case scenario, is a, because you can't have them at the end of any month, in theory, if you had it at the end of the 29th of February in a leap year, it's just, that's gonna be a car crash, that's gonna be really bad. You can, they're not, I don't know why they're called, they're leap seconds, I think that came from leap days, obviously, leap days have been around since sort of Gregorian times, so I don't think, I think they were just borrowed, and in the spec, they're actually called discontinuities, which is kind of polite way of saying, we're just gonna pick up and put it over here now, so. Yeah, it's not pretty, but I think leap seconds comes from leap days, you're right. Any other questions? Yeah. What's your favorite solution for leap seconds? My favorite, I like atomic time, it's really simple, atomic time just ticks away, you just need an array of offsets, and then, and you've got six months to put that leap second in, that's just really simple, if I don't, do we just do that, it makes sense to me, so. Any more leap second questions? Okay, oh, one more. All right, what's your favorite bug that's been caused by a leap second? Oh, that's not my favorite particularly, I just, it's like Christmas, every time it comes around, it's like, what's it gonna be this time, you know, I really love it, it's just like, and there's leap second parties, I don't know if you've ever come across those, but people do have them, and you've gotta work at what you do, I jumped in there the last time, like, that was my second, that's great, yes. You get six months warning for your parties. Is there anything you don't like about leap seconds? They're hideously complicated, yes, they're, I mean, I've really just scratched the surface here, and there's way more, especially when it comes to the technical side of implementing some of this stuff, there's a lot more to it, yeah, it's a headache, I might need a pint, yes. Excellent, well I think we will stop there, so let's all thank John once again. All right, thank you.