16 ms·
Leap seconds: Causing bugs even when they don’t happen
- FabHK 5y agoWhat we'd like to have: 1. Use SI seconds 2. Keep in sync with earth rotation 3. Avoid leap seconds Pick any two: - UT1: 2, 3 (not 1) [https://en.wikipedia.org/wiki/Universal_Time https://en.wikipedia.org/wiki/Universal_Time] - TAI: 1, 3 (not 2) [https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time] - UTC: 1, 2 (not 3) [https://en.wikipedia.org/wiki/Coordinated_Universal_Time https://en.wikipedia.org/wiki/Coordinated_Universal_Time]
- ahubert 5y agoHence, the giant leap second gyroscopes! :-)
- contravariant 5y agoThis is neither here nor there, but "leap second gyroscopes" has turned up some of the weirdest google search results I've seen. A few examples: > Downward movement of work quality? He drew in step a leap second? Gyroscope and accelerometer. Gunfire this weekend outdoors and enjoy shopping here! > Successful troll was a leap second? Gyroscope and accelerometer. Blissful for you. Both inconsequential from a class. Miracle whip classic macaroni salad? > Had lent thee all a leap second? Gyroscope and accelerometer. Shah is threatening hearing or sound. Been fired from their roost and lay siege to the renovation ... Now it's not unusual for webpages to pad their text in order to trick search engines, but these are downright weird.
- zokier 5y agoAfaik additional problem with UT1 is that it's near impossible to tell UT1 time in real-time, because you need to do astronomical observations. So it's kinda impractical as civil time.
- fanf2 5y agoThe rotation of the earth is predictable enough in the short term that it is forecast a year into the future: see IERS Bulletin A https://www.iers.org/IERS/EN/Publications/Bulletins/bulletins.html https://www.iers.org/IERS/EN/Publications/Bulletins/bulletin...
- thaumasiotes 5y agoAs far as I remember from earlier discussion, the reason that problems arise is that the posix standard defines a "day" as 86400 seconds, so leap seconds need to be erased from history after they've happened. This doesn't make a lot of sense; on March 1st, we don't start pretending that February 29th never happened.
- zokier 5y agoWell, POSIX time is an additional layer of stupidity, but it certainly not the only source of problems; notably these GPS/GNSS related problems do not have anything to do with POSIX time
- account42 5y agoThere is no problem with GPS time, only with converting from GPS time to POSIX time or some other leap-second affected time.
- phicoh 5y agoThe problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well. Given that we don't know when there will be leap seconds in the future, this conversion is imposible if we want to take leap seconds into account. So the solution is to either ignore leap seconds (as posix currently does) or have a regular rate of leap seconds (just like leap years). Unfortunately, the rotation of the earth is are not regular enough for a fix rate. At the scale of a human life, leap seconds are completely irrelevant if you want to know the position of the sun. So it is bizar that our civil time has leap seconds. Looking back, that seems to be a historical mistake.
- thaumasiotes 5y ago> The problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well. > Given that we don't know when there will be leap seconds in the future, this conversion is impossible if we want to take leap seconds into account. The conversion is impossible anyway. We don't know what the calendar will look like in the future. That isn't a problem that can be solved by any means.
- qalmakka 5y agoJust stick with TAI and convert times to UTC when displaying them is required. The real crap here is the C and POSIX time_t type and its related functions, which are massively out of date (like the 70% of the C standard library). The ISO C standard committee is way too scared of breaking stuff, and when they add something is often utter garbage (look at the whole _s functions fiasco in C11).
- TazeTSchnitzel 5y agoThey should be scared of breaking stuff! If newer standards break things, those newer standards are unlikely to get wide adoption, which prevents actual progress. In any case, while the POSIX and C standards need to accommodate atomic time, that's not enough. The software on top needs to switch to atomic timestamps too.
- qalmakka 5y agoC++ is being adding basically both the kitchen and the sink for years now and still it hasn't broken anything. If anything, lots of warts have been removed now. This whole reasoning doesn't hold when the ISO C standard adds half-assed, optional rubbish to the C standard only to deprecate it the next release. The ISO C can't create a newer, saner C string library or a more useful time library, but it finds the time to devise and release crap like VLA, threads.h or _s functions. Meanwhile, C++20 has stabilized std::chrono::tai_clock, which works on all major operating systems, and does not break anything.
- nly 5y agoC++ is getting timezone database access in stdlib soon too
- akira2501 5y ago> and still it hasn't broken anything. Well, when you explicitly throw ABI backwards compatibility out the window it's far easier to make that claim.
- TazeTSchnitzel 5y ago
- vitus 5y agoSmear it! You sacrifice 1 on days with leap seconds (by 0.001%), but otherwise have all three. https://developers.google.com/time/smear https://developers.google.com/time/smear
- michaelt 5y agoAh yes, for people who want to support leap seconds, but who can happily ignore a clock error of 0.5 seconds :)
- vitus 5y agoI like to think of it as UTC being off by 1s just before the leap second. :)
- q3k 5y ago... I wouldn't call it an error? It's an offset between smeared UTC and non-smeared UTC, like between any two other time standards. It's internally consistent, and for communicating with external entities that expect unsmeared UTC you convert as needed as much as possible. No different from if you were running TAI and communicating with unsmeared UTC, or communicating with TAI while running unsmeared UTC.
- contravariant 5y agoKind of, but differences in time will forever deviate from the SI second so I don't think that really counts. Also 0.0001% of the distance to a GPS satellite is on the order of 200m. Not impossible to work with, but not great either. Though I have no idea what the exact ramifications would be.
- sebzim4500 5y agoRight but as long as GPS satellites are synchronised with each other it doesn't matter all that much how synchronised they are with anyone on the ground, the position they return will still be correct.
- dooglius 5y agoWho is the "we" who wants to keep "in sync" with the Earth's rotation to such high precision? Obviously having 3:30 pm suddenly become the middle of the night would be bad, but we're talking a delta of 18 seconds spread over almost 50 years... hardly big enough to be called "out of sync" in any noticeable sense. Maybe in a millennium or two we'll lose the cultural context of what "it's 5:00 somewhere" meant, but I'm sure the historians could add a blurb.
- globular-toast 5y agoAgreed, 2 seems way lower priority than the other two. You already put your clock "out of sync" with the Earth's rotation every time you move East or West. Nobody actually cares about this. 1 hour timezones are generally granular enough for our needs.
- smichel17 5y ago+1, seems like leap seconds could be covered via a leap hour every 10k years or so. Implemented as a daylight savings change that gets skipped. Implement it at the level of time zones, which is complexity that we already have to deal with most of the time when we want to interface with humans.
- layer8 5y ago> seems like leap seconds could be covered via a leap hour every 10k years or so. The increase is quadratic. Without leap seconds, the difference will be an hour in 1000 years, but already a full day in 5000 years. https://www.ucolick.org/~sla/leapsecs/dutc.html https://www.ucolick.org/~sla/leapsecs/dutc.html -> Effects of disconnecting time from the sun
- smichel17 5y agoAh, that does complicate things. It's not totally clear to me why they think "Given that the first leap hour would not happen for centuries, it is not clear that any systems (legal or technological) would build in the necessary complexity for handling it." It seems like that infrastructure is already in place— the IANA time zone database, and associated technology. UTC would become disconnected from sun-time, but all the other zones could shift relative to it, and it seems like most things would continue to handle it as expected. But, I also trust that other folks have thought about it in more depth than I have. I'm not seriously trying to solve the problem (If I were, I'd get involved in standards committees or similar), and I'm happy to concede that my solution misses key details :)
- account42 5y agoTAI sounds perfectly reasonable for most systems and should be the default IMO - only when displayed to humans do we really need to care about syncing up with the earth's rotation.
- deleted 5y ago[deleted]
- lifthrasiir 5y agoUTC with only leap hours will satisfy all three, assuming 2 can be slightly weakened.
- zokier 5y agoYou can even avoid leap hours if you are willing to have Greenwich not be at +00:00 timezone
- contravariant 5y agoClearly the most realistic solution is to slow down the rotation of the Earth when necessary.
- richardwhiuk 5y agoI think you mean speed up.
- fanf2 5y agoYou need to be able to do both! Since the start of atomic time the day has generally been about 1ms longer than 24x60x60 seconds; at the time of the last leap second in 2016 it was 1.5ms longer. But since last year it has been slightly less than 24x60x60 seconds! For the last few months it has been around 0.25ms shorter.
- contravariant 5y agoWell either way would work I suppose, but yeah let's speed it up a bit. I propose we move the moon closer.
- denton-scratch 5y agoOne of the things we want is a timescale that allows us to put a timestamp on a contemporary event, with the hope that in 2,000 (or 200,000) years, they will be able to work out exactly how long ago it was we were referring to. GMT failed disastrously at that; there have been about 12 mutually incompatible definitions of GMT over the years. So, UTC should retain leap-seconds; that's what UTC means. A new timescale, without leap-seconds, MUST have a new name. I'm betting the ITU will just change the definition, without changing the name.
- themulticaster 5y agoI think you're looking for TAI. UTC = TAI + Leap Seconds (unless I'm missing some minor detail). You don't know how many seconds lie between arbitrary UTC timestamps in the future, but you do know how many seconds lie between arbitrary TAI timestamps in the future.
- echelon 5y agoExactly. The position of the sun doesn't matter that much. Many locations already do daylight saving and would actually prefer to switch their clocks to "saving time", which moves the sun to a point that isn't highest at noon. (As if it actually mattered to keep the sun fixed.) We can always calculate where the sun and stars were positioned if we care.
- Uberphallus 5y agoWorth mentioning, there's an ongoing debate about removing leap seconds, as they seem to cause more trouble than benefit they bring (UT1 and UTC being in sync). Personally I've dealt with some unit tests around simultaneous use of multiple timezones (we had to show the timestamps in the local timezone of the respective event). One day a good chunk of them stopped working for no apparent reason. After a lot of head scratching, I figured out an update of tzdata was responsible for it, since it added new planned leap seconds. Our underlying library was properly taking the leap second into account, but the test conditions weren't.
- nly 5y agoAt my work we have a system where dates are in a local timezone, where the timezone depends on the data ingress point, but times are in New York local time. So many bugs occur when juggling 2 or 3 timezones simultaneously.
- quietbritishjim 5y agoI won't name it, but I can guess where you work, as the place I once worked had the same problem and surely not many places have made the same mistake. Worst is where the NY local time jumps back due to DST and you have two actual points in time represented by the same numerical NY local time. That manifests itself as an hour long gap in the data for the Australian stock exchanges!
- nly 5y agoIt shouldn't be problematic as long as the exchange stops trading for at least 2 out of 24 hours, since no DST shifts can bridge the gap and cause ambiguity. 24 hour exchanges are hosed though Where do you work now and what mistakes have they made? :P
- quietbritishjim 5y ago> It shouldn't be problematic as long as the exchange stops trading for at least 2 out of 24 hours, since no DST shifts can bridge the gap and cause ambiguity. Actually one hour would do, but it has to coincide with New York 1am - 2am, not its own DST shift. If I remember right, only one or two exchanges had that problem in practice even though there are lots of Asian exchanges. In fact it might've been the New Zealand stock exchange rather than the Australian one. But yes all 24 hour exchanges are in trouble. This was a good 10 - 15 years ago now, so it's possible they've added a suitable hack to "solve" the problem. I work for a small consultancy now where much of the software design choices were made by me. So naturally there are no mistakes ;-)
- eerikkivistik 5y agoThis could lead to an interesting situation, where in June of 2029 a multitude of double-spending attacks are initiated on various banking/financial software across the world, with the attack lasting a few seconds in total. What a headline that would be... Of course this depends on specific implementation, but I can see how this could happen to a wide array of implementations.
- makeitdouble 5y agoLooking at how banks handled these kind of issues in the past, they'll shut down all operations for these few seconds and throw away anything that still came in these seconds as invalid. It sucks for their customers and partners, but that would be a decent conservative option I think.
- MiddleEndian 5y agoSomebody should have told the financial institutions in Batman: The Dark Knight Rises that throwing away very obvious unwanted transactions was an option!
- makeitdouble 5y agoOn one side it might not be a good idea to have actual actionable and efficient criminal plans enacted in popular fiction. On the other side, it seems to be a disservice to the community to have stupid ideas widely spread around. It's hard to balance for sure.
- debarshri 5y agoOne of the interesting corner cases of leap second is in traffic enforcement. It you are building section control traffic enforcement system, you measure the t1 at point on entry and t2 at exist. Because of you know the length of a section , distance over time difference becomes your speed. But when you have leap second, you might just get a fine for driving at jet-fuelled speed on your grandpa's car.
- adrianN 5y agoI really hope that traffic enforcement systems don't use timers that know the date.
- debarshri 5y agoIt is not just for timer, as part of evidence you also have to capture when that event occurred. There it does capture the date.
- q3k 5y agoYou should record the event time separately [1] from the beginning/end of the measurement period - the first as a time instant in UTC ('wall clock'), the latter as a difference between two values of a guaranteed monotonically increasing clock. This is something you need to do regardless of leap seconds to handle things like NTP kicking in to adjust your local wall clock time. [1] - Depending on the programming environment, these might be either different timestamp types recorded separately or converted appropriately to reflect different uses, or a smart combination type like time.Time in Go.
- Faaak 5y agoSupposing the speed-controlled road spans 1km, then if you go at 100km/hour, it will take you 36s: You have: 1km/(100km/hour) You want: s * 36 With a second less, your speed would be miscalculated to: You have: 1km/(36s - 1s) You want: km/hour * 102.85714 So not really something to worry about
- 5y ago
- edward 5y agoPrevious discussion: https://news.ycombinator.com/item?id=27944776 https://news.ycombinator.com/item?id=27944776
- deleted 5y ago[deleted]
- deleted 5y ago[deleted]
- kortex 5y ago(One of) the biggest pains with leap seconds is they are so infrequent and so I/O-bound, that they are almost impossible to test. What is less functional than relying on a random change in a radio signal below the noise floor coming through dedicated hardware, which is finicky and doesn't work well indoors (E-coated glass windows? Fuggetaboutit). I think one thing that could have be easily done to help is emit leap-sub-seconds (100-500ms) more frequently, so we would have more chances to detect bugs per year. Alas, leap seconds are baked in as int8 so that's never gonna happen. That's also totally not the mindset when these systems were designed, which is kind of my point. The right kind of forethought could have avoid much of this pain. Option 1: We have 2 time standards out of sync. Let's make an announcement yearly-ish and add 1 second of offset that everything has to obey. Option 2: We have 2 time standards out of sync. Let's continuously track the offset to (whatever precision) and this offset is just always part of the correction (like we do time zones), rather than this value which you just assume is static 99% of the time.
- trzy 5y agoWe had a leap second bug on the options trading desk I worked on that brought down our system. As market makers, we had an obligation to keep providing liquidity so this was a serious issue and exposed us to fines. Our exchange co-located data centers used GPS for precisely synchronized timestamp generation but the firmware on some of the GPS hardware had a bug and failed to take into account a leap second. When that leap second was to be inserted, they became out of sync by a second. We generated spot price feeds from each location and a component that consumed these feeds would check to ensure that they were not stale (any data more than 0.5 sec old could not be used as an input for pricing and trading). Well, a lot of exchange feeds started looking stale, and our system stopped quoting on said exchanges. First there were some murmurs from the traders and within minutes the entire room hit a crescendo of panic. It took, I think, the better part of an hour to debug.
- 8ytecoder 5y agoHow did you resolve it?
- omegalulw 5y agoThey just needed to add leap seconds to the hardware timestamp after they debugged it.
- hacker_newz 5y agoCan you provide the model of the GPS hardware? I work in the same industry and have set up multiple NTP / PTP timer servers that have never failed to account for leap seconds. It's almost always the downstream software that crashes. See the 2012 leap second insertion as an example.
- fhars 5y agoI am still in favor of replacing the annoying one hour jumps when switching to and from DST by having a leap second nevery hour for 150 days. That would also force people to fix their leap second bugs.
- platelminto 5y agoIs there somewhere to read more about this? It sounds very interesting, are there any places/systems that are considering using this, or even talking about it?
- _moof 5y agoOffered for perspective/interestingness, not as an argument: For anyone wondering why it matters so much that time be precisely linked to the rotation of Earth, I'll note that time is a fundamental component of navigation. When you do celestial nav you make corrections down to the second, including accounting for the number of seconds your watch gains or loses. So it's not just about putting timestamps in a database. There's a straight line (a rhumb line? har har) from "what time is it" to "where are we" and in that context losing a second means you get a different longitude. Because time in this setting isn't really time--it's an indication of how far east or west of the prime meridian the sun is.
- drallison 5y agoLeap seconds are a bad idea and should be abandoned. Computing the time between events by subtraction should work. And while we are at it, dropping time zones and daylight saving time would also make sense.
- jameshart 5y agoSo many comments on here asserting that leap seconds are bad and should be abandoned and that it would be simpler if they didn’t exist, but… You realize this is about the GPS system, right? The thing about GPS satellites is that they are in space, orbiting around the earth. If the earth’s rotation speed changes their orbital speed doesn’t (not immediately, anyway). GPS absolutely needs to adjust for the variable rotational speed of the earth - otherwise the GPS coordinate grid would gradually move relative to the surface of the earth. So GPS doesn’t exactly need leap seconds but it really does care about how long a rotation of the earth takes which… amounts to the same thing.
- daddylonglegs 5y ago> So GPS doesn’t exactly need leap seconds but it really does care about how long a rotation of the earth takes which… amounts to the same thing. I don't think this is right. GPS explicitly uses a timebase that does not include leap seconds [1]. On the subject of the article: my modest and very reasonable proposal is that we apply a leap second every six months without fail, dithering between positive and negative leap seconds so as to remain close to sidereal time. That way we would flush out bugs every six months and wouldn't have them accumulate and hit us all at once. Or we could be boring and use TAI or GPS time as the system clock every where and apply leap second corrections when we go from the system clock (currently UTC) to local time. [1] https://en.wikipedia.org/wiki/Global_Positioning_System#Timekeeping https://en.wikipedia.org/wiki/Global_Positioning_System#Time...
- jameshart 5y agoI mean, the article is literally about GPS satellites transmitting leap second data as part of their messages. So yes, the basic clock is just counting seconds but leap seconds are a pretty important component of the GOPS model.
- a1369209993 5y ago> GPS absolutely needs to adjust for the variable rotational speed of the earth Sure, but that's a spacial thing, not something that's relevant to timekeeping. (There's technically a change in relativistic time dilation, but it's less than a rounding error - about five millimeters per second at the equator makes 1.000000000002388402 versus 1.000000000002388457 if I've got my math right. (The relativistic time dilation from the earth's rotation is itself a rounding error.))
- beervirus 5y agoEvery time I read an article about time handling in software, it makes me glad that’s not how I earn my paycheck.