30 ms·

It’s time to leave the leap second in the past

• treesknees 4y ago
  >remain at the current level of 27, which we believe will be enough for the next millennium. I would have loved to read more justification about _why_ Meta thinks we no longer need the leap second beyond calling it a community push. They did a great job of complaining about how hard it is to solve from a technical perspective, and then explained how they solved it. Is the only problem really that Meta doesn't know how to test a negative leap second?
  • wutbrodo 4y ago
    They explain this at the top of the article: > This periodic adjustment mainly benefits scientists and astronomers as it allows them to observe celestial bodies using UTC for most purposes. If there were no UTC correction, then adjustments would have to be made to the legacy equipment and software that synchronize to UTC for astronomical observations. > While the leap second might have been an acceptable solution in 1972, when it made both the scientific community and the telecom industry happy, these days UTC is equally bad for both digital applications and scientists, who often choose TAI or UT1 instead. The claim is that the benefits accrue primarily to a community whose relative importance is minuscule compared to the broader software world in 2022. The tradeoff was made in 1972, when astronomers etc represented a vastly larger proportion of software.
    • whimsicalism 4y ago
      Why can't large tech companies that need synchronization similarly switch to an alternative time without leap seconds?
      • seoaeu 4y ago
        Because time in the real world uses leap seconds. The time businesses open and close. The times reported in news articles. And so on. What facebook wants is for all of them to stop using leap seconds so facebook’s infrastructure is simpler
        • gowld 4y ago
          It's not just Facebook. A large community doesn't want them. https://www.cl.cam.ac.uk/~mgk25/time/leap/ https://www.cl.cam.ac.uk/~mgk25/time/leap/ Time in the real world can use leap hours, the next of which will be in approximately 3000 years.
          • yebyen 4y ago
            The article you linked seems to be arguing pretty strongly against leap hours. I'm not sure we could solve all those problems even in 3000 years. Can we compromise and use leap minutes? That way the problem is a bit more immediate, in 50 years we're sure to have solved it; or we'll all be dead and it will be on someone else!
            • School-Cotton 4y ago
              Instead of leap hours we could just permanently abandon leap anything, and state that the offset between UTC and TAI is fixed at 27 seconds from now on, forever. Every few thousand years, when this new UTC has drifted enough from solar time on the prime meridian for people to start noticing and caring, countries can decide to simply change their offset from UTC, which will just be a normal update in the time zone database that doesn’t need to be coordinated with anyone else, i.e. something that already happens quite regularly. This is all quite hypothetical as it’s hard to predict whether anything like our current technological civilization will exist thousands of years from now, but even if it does, a simple mechanism exists to avoid problems (just have each jurisdiction change their local time when they decide they want to). I can’t see any downsides for literally anyone from this proposal, other than the insignificant downside to the British that they will lose the prestige of being the place that global standard time is based on.
              • nullc 4y ago
                Yep, either just redefine the timezones-- or perhaps better just issue new "New Eastern time" that is offset by an hour. > lose the prestige of being the place that global standard time is based on. You joke, but that's actually a source of some of the opposition. :(
      • b112 4y ago
        Worst part is, the arguments are a bit silly. Time may change forwards and backwards, because my computer clock may be fast or slow. The same logic to correct for leap seconds, can be used if my computer is 2 sec fast. And your code had better handle it, and the os, libraries, it really is only hard ), if you have to support 1000s of novice devs.
        • shadowgovt 4y ago
          And FWIW, every major company does have to support a thousand novice devs, every year, over and over, forever. Honestly, this issue screams education problem. "Time is a mess" should be taught alongside buffer overflow attacks and networking theory (in fact, networking theory is a great place to teach "time is a mess," because you can roll it in alongside ideas like "simultaneous action is a lie" and "clocks are always wrong anyway").
      • adrian_b 4y ago
        Because they are lazy and are not aware of the prior work. Already decades ago many have proposed to use only TAI internally in computers, instead of UTC, which is not a time. UTC should have always been used only to compute the local times, together with the time zones, only for human interfaces. There have been for decades libraries for using TAI instead of UTC, and even versions of Linux or *BSD kernels patched to do time keeping in TAI, not in UTC, eliminating all problems with the leap seconds. Unfortunately the use of TAI has remained a niche, but that was the right solution.
      • nullc 4y ago
        Because they have to interact with the rest of the world, and billions of lines of computer software and hundreds of thousands of protocols have been written to use UTC instead of, say, using TAI and computing UTC on a presentation basis like timestamps are handled.
    • crote 4y ago
      The thing is, similar reasoning can also be used to promote getting rid of leap years. Heck, maybe just switch to 12 months of 30 days while we are at it. If you want to use real-world time, you have to make sure it stays in sync with the real world. Switching to something which is close-but-not-quite-correct will cause even more issues than we are currently having with leap seconds. Can't deal with that? Well, just use the Unix timestamp like the rest of us?
      • dylan604 4y ago
        Yeah, if it wasn't for that pesky requirement to keep in sync with the wall clock, my life would be so so so much easier not having to deal with drop frame timecode. The video industry isn't exactly small, and nobody has just up and decided "meh, it's too hard, so we're going to push the everyone else to do what we want". We all put on our big boy&girl pants and do the work.
        • makeitdouble 4y ago
          The video and music industry has been screwing a lot of our digital lives with mandatory encryption and anti hacking/reverse engineering requirements just to sustain some of their business models. The abstraction layer is different than this, but god the irony.
        • zerocrates 4y ago
          Of course, drop-frame timecode itself imperfectly compensates for the fractional framerate, and also as a result of the math not really working out there isn't a drop-frame standard for 23.976 fps at all, so sometimes the industry just throws up its hands and says "meh, it's too hard."
          • dylan604 4y ago
            It's not that they don't have DF for 23.976 because it's hard, they don't because it wasn't needed. A 23.976 framerate was never broadcasted as it wasn't part of the NTSC standard. In fact, rarely did anyone actually edit at 23.976 unless it was going back to film. They cut the telecined film as 29.97 video with no regard to A-frames or any other methods that would enable the edit to cleanly go back to source frame rate. They so didn't care that some times the film cadence changes on every single edit. Why? Because nobody needed it nor could they possibly imagine the time of the internet and digital streaming that could do any frame rate to even bother wasting time trying to do it "right".
    • treesknees 4y ago
      I can see that, but I disagree that it's enough of an explanation. The blog specifically gives an example of the Earth's angular velocity changing with the melting of ice caps. They even threw in a cute animation of an ice skater to explain it. Last I checked, we're in the midsts of global climate change which is rapidly melting our ice and raising sea levels. I'm supposed to take Meta's word that we'll never need another leap second then? Why is that the case? Instinctually it makes sense to me to have a clock that follows the Earth's rotation. Why does Meta believe this is no longer the case? The only justification I saw was "it's hard" followed by their explanation of how they've solved it already. So what is the problem that's being solved by not counting leap seconds?
      • shadowgovt 4y ago
        So, time is a human construct and Earth doesn't care how we measure it. It's not that we'll never need another leap second; we could add ten, negative ten, or zero in the next 25 years and Earth won't care. Who will care are humans, who may get a bit annoyed when the sun starts setting in equatorial latitudes at 3PM.
        • mjamesaustin 4y ago
          Based upon the historical trajectory, it would take around 6,666 years for time to be offset by 1 hour.
    • jrichardshaw 4y ago
      Actual research astronomer here, and as a (radio) astronomer I would love to get rid of leap seconds. Assuming that UTC = UT1 (the time measure based on Earth rotation) is not accurate enough for most calculation such that you already need to use UT1 tables/forecasts and leap second tables in your ephemeris calculations so there isn't really much benefit in trying to keep UTC close to UT1. And the reality is that for us they actually make things worse: we stop data acquisition at the telescope over the leap second period because we timestamp our data in UTC dealing with the changing interval would be a pain. There are some good arguments for keeping leap seconds, but I don't think research astronomy is really one (it might be more useful for amateurs), particularly on ~100 year timescales where you don't expect things to slip that much. I think this sentiment is shared by most of my peers, particularly those who actually have to implement data acquisition and analysis pipelines!
    • wongarsu 4y ago
      I can't imagine people who need accurate timekeeping (like scientists, astronomers and the telecom industry) preferring UTC over TAI. They do however prefer UTC over UT1. UTC was a reasonable compromise in the sense that it's almost TAI, but is close enough to UT1 that you can get all countries on board without much effort. Imagine getting the whole world on board to accept a mysterious device that counts electron transitions, without giving some kind of reassurance that it won't deviate in any relevant way from the timekeeping system they are used to.
  • ForHackernews 4y ago
    I'd wager Facebook will not survive the next 50 years, so they probably don't need to worry about the next millennium.
    • galdosdi 4y ago
      You're probably right about the corporation, but some of their component organizations and assets may survive as long or longer, albeit after being resold, merged, acquired a few times. It could happen, you never know. After all, there are still pieces of the original Bell organization and infrastructure around in active use, just with the names on the business cards and buildings changed. I don't think someone 50 years ago could have predicted which parts would still be around and which long gone.
    • oofbey 4y ago
      We can all hope as much.
  • psanford 4y ago
    Facebook will be able to test and handle a negative leap second better than most organizations in the world. Its everyone else they are worried about. If the rest of the internet breaks from a negative leap second, it doesn't really matter if facebook's servers all stay up.
• edent 4y ago
  I can't quite reconcile the FB attitude of "we only hire the best and brightest after making them demonstrate their technical prowess" vs "computers are a bit hard please can everyone change everything to make it easier?" Why not just agitate for a move to French Revolutionary Decimal Time as well?
  • dastbe 4y ago
    This is not a case of "computers are a bit hard", it's a system that we've imposed upon ourselves that has been repeatedly demonstrated to be unsafe. because of this, we've ended up with many (many) solutions baked into software that attempt to abstract away the sharp edges of this problem from individual engineers, which leads to inconsistent assumptions about what you need to consider when writing code. even with the best and brightest engineers there is a non-trivial probability that someone will make an assumption that is invalid based on their understanding of what can happen (ex. leap seconds never go negative!) or the library their using (this ensures monotonic time!) that could lead to disastrous results. and especially at meta scale, that probability is no longer "will someone make this mistake in our code?" but is "how many times will people make this mistake in our code?", so systemic solutions that eliminate this as a class of problem an individual can create is something we should consider.
    • tgv 4y ago
      > could lead to disastrous results You mean some influencer's timeline could get messed up? The horror!
      • User23 4y ago
        Reddit was down for almost an hour!
      • dastbe 4y ago
        whether you like it or not, people are using facebook (and google, and amazon, and so on) as critical infrastructure. there are also all the other companies out there who do not have the platform that meta has that can also hit the same issues. i'm sure some of them have products you wouldn't be so glib about.
• dmm 4y ago
  Another solution would be to add an extra positive and negative leap second every year to make sure all those code paths are tested.
  • throw0101a 4y ago
    The FreeBSD folks run tests on positive and negative leap seconds to make sure things are fine: * https://lists.freebsd.org/pipermail/freebsd-stable/2020-November/092837.html https://lists.freebsd.org/pipermail/freebsd-stable/2020-Nove... Of course there's a whole lot of other userland code besides ntpd.
  • ble 4y ago
    It could be a holiday / hazing event for software engineers.
  • ncmncm 4y ago
    I.e., half of everything is broken each 6 months, instead of just every 15 - 30 months. Better would be half of everything not breaking every 15 - 30 months.
• LeoPanthera 4y ago
  It's frustrating that programmers want to redefine civil time just because it is "hard". This article glosses over the real world problems that detaching from UTC will cause. This article details some of the problems: https://www.ucolick.org/~sla/leapsecs/dutc.html https://www.ucolick.org/~sla/leapsecs/dutc.html (You may want to scroll down to "Implementing the plan outlined at Torino".) If we end leap seconds, it doesn't take long - only until 2028 - until "midnight" is sufficiently far from "the middle of the night" that you will have to consider the legal issues caused by events that happen just before or after 0000 hours. By 2055, the "minute" displayed on a clock may be incorrect, which again may cause issues with legal timestamps. And by 2083, sundials are measurably wrong. All because programmers wanted to save some lines of code.
  • lesam 4y ago
    Sundials are already ‘wrong’ according to solar time by 30 minutes or more, as an artifact of dividing the world into hour-wide time zones. Astronomy already ignores leap seconds in the same way that modern finance ignores half-crowns and shillings.
    • welterde 4y ago
      Astronomy very much relies on the leap seconds. If they ever get abolished it will create lots of headache for all observatories (and hobby astronomers as well), since the telescopes will point more and more incorrectly as UTC drifts away from UT1 (the leap seconds ensure UTC is always within 0.9s of UT1). To explain a bit further: UT1 tracks the Earth's rotation relative to distant quasars and is thus directly the correct clock/reference to use for pointing telescopes. However it doesn't advance at a nice and stable constant frequency, but something that slowly changes over time (and can shift by strong earthquakes) and thus we approximate it with UTC, which runs at a nice constant frequency, but needs occasional correction to match up with Earth's rotation.
      • philwelch 4y ago
        I think we can allow astronomers to keep their leap seconds without requiring them to be imposed on the entirety of civil society.
• jheitmann 4y ago
  Why does ntpd lose the smear on a restart? I would have thought that the current smear could be calculated purely based off current non-smear time, plus the config to say when to smear, which is presumably available upon restart. Also, why were non-linear smears thought to be desirable? Googling just turns up hand-wavy phrases like "easier on clients".
  • hocuspocus 4y ago
    I came to the comments for the same question about non-linear smearing. I found more details and motivation in this article: https://developers.redhat.com/blog/2015/06/01/five-different-ways-handle-leap-seconds-ntp https://developers.redhat.com/blog/2015/06/01/five-different...
  • randyrand 4y ago
    Ya this sounds like bad design. > current non-smear time This is the server that keeps that time! ;) But IMO, the time keeping device should be a separate hardware module with battery backup that is never is restarted. The computer should not be keeping time to begin with.
  • almog 4y ago
    That was my thought too, pointing out why NTP smearing might be fragile is a crucial point in any argument against leap seconds, and the reasoning in this post are lacking (regardless of the conclusion's correctness). My only guess is that because smearing takes place at Stratum 2, if the network partitions part of the NTP servers downstream (Stratum 3+), they'll have an offset as large as T/(17 x 3600) (T being the partition duration in seconds). Yet I guess it must be something else for I cannot see why that won't be tolerable. More generally AFAIK the NTP RFC does not include smearing period, which is why the best practices are to only use smearing in a well controlled environment rather than on public facing NTP networks, but why is this not something that can be fixed? I'm not sure.
• deleted 4y ago
  [deleted]
• deleted 4y ago
  [deleted]
• klyrs 4y ago
  Weird, I came to a different conclusion after reading the article. There's already a graceful solution to non-monotonic time, which mitigates most of the problems: smear, don't leap. Only, it's not a universal solution, so various systems are out of sync during the smear. Solution: petition for a standardized smearing strategy. But yeah, leave "leap" seconds in the past. And, maybe, don't run sub-second benchmarks with a wallclock.
  • daine 4y ago
    If smearing were adopted as standard, the "seconds," "minutes," and "hours" appearing in timestamps would no longer correspond to literal seconds minutes, and hours of duration, even in principle. That seems very misleading and bad.
  • ncmncm 4y ago
    Smearing is absolutely the worst of all possible choices. Instead of one second, you are out of sync with the whole world for all of 24 hours. And you are fooling with things for the whole period. Of course it was Google who picked the worst of all possible choices.
    • joshuamorton 4y ago
      But, its practical success does in many ways prove that mild inconsistencies between different time systems are...fine, and so a leap-less approach wouldn't cause any issues.
    • klyrs 4y ago
      No, the absolute worst possible choice is geoengineering -- literally moving mountains to correct the effective radius of the earth.
      • ncmncm 4y ago
        There is this word "possible" there. You might call the biggest earth-moving company in the world and see if they will give you a quote for that.
• shadowgovt 4y ago
  So what's the alternative? The leap second is capturing an actual skew between uniformly-ticking clocks based off of atomic decay statistics and the rotation of planet Earth. Stop updating them, and we end up with the sun going down for equatorial latitudes at 3PM eventually. This feels very can-kicky, even if the can can be kicked a thousand years down the road. I don't think more can-kicking is really the best solution.
  • wmf 4y ago
    Once the discrepancy exceeds 30 minutes you change the time zone offset.
    • shadowgovt 4y ago
      So their complaint is that one-second skews happen infrequently enough that they are always a headache, and we want to "solve" the problem by... Replacing it with a less frequent time modification that introduces larger delta? I've been on the front lines of adapting code for a novel timezone change. It wasn't pretty.
      • ncmncm 4y ago
        It is not, ever. Doing it every year or two imposes just as much disruption every year or two. A disruption once a century is at least 50 times less disruption.
      • wmf 4y ago
        Globally, time zone data changes all the time (more often than leap seconds) and thus software is better at dealing with it.
• kstrauser 4y ago
  Counterpoint: no. The hubris of “we’d rather not do this, so let’s make the entire rest of the world deal with it instead” is impressive.
  • dymk 4y ago
    God forbid somebody suggest a solution to a problem.
    • kstrauser 4y ago
      When the problem is “this is too hard for us (but apparently not our peers)”, a valid solution is not “let’s just ignore it, even though our idea would cause an enormous pain in the neck for the rest of the world”.
      • dymk 4y ago
        Why do you think it's not also too hard for their peers? Any company with an interest in time keeping spends tons of money dealing with time zones and leap seconds.
        • kstrauser 4y ago
          Because I haven’t seen the Google or Amazon proposal to ditch it. Perhaps they’ve written them and I don’t know about them, but I’m not aware of them. We do lots of things that are hard because doing them right is often more important than doing them easily. Switching from ASCII from UTF-8 was a pain, but we did it. Software upgrades are a pain. Security infrastructure is a pain. Timezones are OMG such a pain. But in all those cases, we collectively said “welp, guess we’ve gotta do it”. And what Facebook notably didn’t propose was a way to actually make this happen. Who’s going to project manage the global coordinated effort to migrate the planet to Facebook Time? That sounds like much more work than them just fixing their time handling.
          • Yujf 4y ago
• sharikous 4y ago
  A monotonic clock without leap seconds could be kept next to UTC, it can easily be standardized. The idea that this problem is so hard that users have to be inconvenienced to the point that reality is ignored is a bit strange to me.
  • dexwiz 4y ago
    This is literally what the TIA standard is. Anything that needs precise time already uses this standard.
  • deleted 4y ago
    [deleted]
  • adrian_b 4y ago
    The problem is that UTC, despite its name, is not a time (it is an angle rounded to a multiple of 1/21600 right angles). Only TAI is a time. Already decades ago, some programmers have argued that internally all computers and their software should use only TAI, which is a time, so it behaves as expected, while UTC must be used exactly like the local times and the time zones, only at the interfaces with humans. If that proposal would have been adopted, there would not have been now any discussion about the leap second. The only reason for the existence of UTC is to keep dUT1, i.e. UT1 - UTC, under 1 second. If the leap second is eliminated, then dUT1 will grow over 1 second, so there are other cohorts of hardware devices and software applications that must be updated in order to no longer rely on the assumption that dUT1 is less than 1 second. Anything that has any relationship with astronomy, e.g. for observations or for navigation, relies on computing UT1 (i.e. the angle between the mean Sun and Earth) from time, so it would have to be updated. Changing the definition of UTC would make it completely redundant, Instead of giving up to add leap seconds to UTC, it would be much better to make a final leap of a half of minute and have TAI = UTC after the date of the big leap. Having 2 identical times with an arbitrary offset between them would just add needless complications to all time-related software, forever.
    • kortex 4y ago
      > The problem is that UTC, despite its name, is not a time. Could you elaborate on what you mean? What is UTC if not a time? Like, datetimes vs time? Even if Unix time was based on TAI, you'd still need leap seconds in order to resolve the correct local time (which is based of even-minute offsets of UTC). Maybe it's easier to deal with in calculation post-hoc vs smearing on the day of, but that handful-of-accruing-seconds will always be there.
• rossdavidh 4y ago
  Situation: there's a problem, and our current way of coping is something we've done 27 times so far. Reaction: let's stop using the system we have some practice at doing, and instead open up the question again, but really just have big tech corporations dictate to the world that we need to do something else.
  • SoftTalker 4y ago
    Might be before many people's memory here, but Swatch tried to create an "internet time" in the late 1990s. Nobody uses it because it doesn't solve any problems anybody has, it's just different.
  • jefftk 4y ago
    We may soon have the first negative leap second. This isn't something we've ever done before.
  • ncmncm 4y ago
    27 times, badly. Every time, 27 times over, it has been a serious hassle, for exactly zero benefit to anyone. Choosing not to impose a hassle and source of bugs on millions of people every year or two is obviously correct. Anyone who wants to use what astronomers use will still be free to do that, without bothering literally everybody else.
• throw0101a 4y ago
  Should we also get rid of leap years because programmers regularly screw those up? :)
  • lucb1e 4y ago
    Alternative solution: get rid of the programmers so you can have leap years
• dexwiz 4y ago
  Fun thought, we have only ever had positive leap seconds so far, due to slowing of the Earth's rotation. However, we could have a negative leap second. The rotation has just been consistently slowing since we started caring. But it could speed up again the future. We can predict rotation speed to a certain degree, but not completely. That is why leap seconds are announced only a few months in advance, instead of years. https://www.timeanddate.com/time/negative-leap-second.html#:~:text=A%20negative%20leap%20second%20is,introduced%20in%20the%20early%201970s https://www.timeanddate.com/time/negative-leap-second.html#:....
  • kortex 4y ago
    I don't think we will ever need a negative leap second. We can just wait longer until dispatching the next positive one. The only situation in which we'd need a negative leap second is if Earth's rotation were consistently speeding up over many years. But we can tolerate some wiggle room (as in, several seconds) between UTC and TAI (since it's not in lockstep anyway).
    • adrian_b 4y ago
      The problem is that there are hardware devices and software applications, which compute UT1 (the angle of the mean Sun) from UTC and from dUT1 (which are transmitted both on various communication channels, e.g. by radio stations) and all those expect that dUT1 is a number between 0 and 1 seconds. If dUT1 can become either negative or larger than 1, all such hardware and software must be reviewed and possibly upgraded, to no longer make assumptions about dUT1. Communication protocols may have to be changed, if there is no way to encode a negative dUT1.
      • kortex 4y ago
        > If dUT1 can become either negative or larger than 1, Negative values should already be accounted for, afaict. > UTC is maintained via leap seconds, such that DUT1 remains within the range −0.9 s < DUT1 < +0.9 s. I can't imagine why it would ever be constrained to abs(dut) < 1, as that does not appear to be a hard spec anywhere, it's just the goal. But I could see some really stupid implementations, so maybe. https://en.m.wikipedia.org/wiki/DUT1 https://en.m.wikipedia.org/wiki/DUT1
• 0xCMP 4y ago
  Can't help but agree with 80% of this post but strongly disagree with the solution. This feels like a hack that punts the problems to the future. UTC has the leap second cause it's not "real time" and so now we're just gonna never sync up UTC to real time at all? How is that the solution? Either we deal with leap seconds or we need to implement something that can't go backwards and properly models time. Leap seconds seem much simpler... In the end we didn't get rid of SQL cause of SQL Injection. We fixed the frameworks and promoted the solutions. We may simply need to make a push for languages and etc to just properly support time and promote how to do things correctly. It honestly seems easier.
  • IshKebab 4y ago
    > This feels like a hack that punts the problems to the future. I think that's ok if "the future" is 1000 years in the future!
  • jasonwatkinspdx 4y ago
    > we need to implement something that can't go backwards and properly models time There simply is no definition of solar time that can obey this constraint long term, because the rotation of the earth varies, and varies over time in ways we have a limited ability to predict. This is the entire crux of the problem.
    • ncmncm 4y ago
      It is not the crux of any problem, except for, uniquely, astronomers. But they have their own solution we need pay exactly zero attention to. Leap seconds in UTC are just as big a nuisance for them as for everyone else. They have TAI, sidereal time, and this dumb bastard UTC with its own hacked up thing that doesn't match their precise alternative.
      • cryptonector 4y ago
        It's not a problem for astronomers. It's a problem for everyone. It's a small problem for everyone today. And it will remain a small problem for a long time. Eventually it will not be a small problem. Meanwhile, making sure everyone agrees as to the kind of time they're talking about it hard enough.
• fourthark 4y ago
  Eventually we will have to get used to having two clocks, slowly diverging. It’s inevitable because we don’t want hours of slip on Earth and eventually we will move to other planets which certainly don’t want Earth leap seconds.
  • 1970-01-01 4y ago
    NASA has already started down this road! https://www.nasa.gov/mission_pages/tdm/clock/index.html https://www.nasa.gov/mission_pages/tdm/clock/index.html https://www.jpl.nasa.gov/news/what-is-an-atomic-clock https://www.jpl.nasa.gov/news/what-is-an-atomic-clock
• lavishlatern 4y ago
  A lot of people in this thread are criticizing this move, but let me offer an opposite view. One of the largest electronic health records systems has code that predates the UNIX epoch. Much of the time handling code is custom written to deal with this. However, the code was so poorly written that the system would lose data during the double 1 am window that occurs during daylight savings time shift. Hospitals would just shut off all of their computers during this time to deal with it. As the article notes, issues with leap seconds have also brought down reddit and cloudflare. Many people in this thread are treating this like some sort of display of incompetence, but if you've ever written code that deeply interacts with time, you'd know how difficult it is to get right. A sign of a good system is one where it is difficult to fuck up. IMO it is better to guarantee that time always moves forward rather than trying to match computer time to human time.
  • mritun 4y ago
    There’s no need to redefine UTC. If you want a fixed monotonic reference clock you want TAI time (the atomic reference) not UTC. https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
    • lavishlatern 4y ago
      I don't see how replacing all UTC in software with TAI is more realistic than breaking UTC sync with UT1 (isn't it literally doing the same thing?). The whole point is that going forward, leap seconds are going to get harder to deal with. Especially in the case of a negative leap second, which seems like a more "true" y2k-like scenario.
      • Veserv 4y ago
        The difference is that replacing usage of UTC with TAI is a voluntary choice made for each program, but redefining UTC to be a fixed offset relative to TAI, which is effectively just redefining UTC to be TAI, is a forced change on everything everywhere all at once that everybody has to handle because one of their dependencies changed. It would be like silently changing the start of unix epoch time to 1800 instead of adding a new “Unix time since 1800” and asking people to switch.
• omoikane 4y ago
  See also: https://developers.google.com/time/smear https://developers.google.com/time/smear Which says both Google and Amazon smears over a 24 hour period (in contrast to Meta's 17 hour smear).
  • ncmncm 4y ago
    Worst of all possible choices.
• mritun 4y ago
  A million problems started when system clocks were changed to follow UTC (as opposed to local time) and then UTC was conflated with Unix time - a fixed monotonic reference, which UTC is not! Though the ship has sailed, I think it could have been much better if computers were set to follow TAI Time (atomic clock time - unaffected by leap seconds) time than the UTC. UTC is as variable as localtime and should have been treated as such. If fb wants to - they can (and should) use TAI time for system reference. TAI : https://www.nist.gov/pml/time-and-frequency-division/nist-time-frequently-asked-questions-faq https://www.nist.gov/pml/time-and-frequency-division/nist-ti... edit: link
  • vesinisa 4y ago
    This sounds like a sensible solution. If Facebook wants to start using non-UTC time coordination, like TAI, they by all means should try it. They only need to publish their own NTP servers I guess, but that shouldn't be a big problem for an organization of their size. As far as I can tell, TAI will always be offset from UTC by an integer amount of full seconds, and I guess time coordination between large independent systems is mostly useful just when comparing log timestamps (I would guess almost all sensible software uses already account for much larger clock drifts than the current leap second count of 37, right?) After adopting TAI, Facebook engineers just need to remember that their log timestamps are offset by N seconds from all the others.
    • ncmncm 4y ago
      Not all the others. Just those who have not made the similarly wise choice.
  • kosherhurricane 4y ago
    I totally support this. In fact, I would say all computer systems should just use TAI, and display UTC to the user. Someone should fork the NTP protocol to use TAI instead, and go from there (or at least provide tai offset).
    • joerichey 4y ago
• amenghra 4y ago
  IMHO, leap seconds belong at the timezone layer. I.e. ignore it internally and for things like "seconds since epoch". Adjust at display time. Timezones are already backed by a database which needs regular updates, including leap seconds would make sense since those are also updated in an unpredictable manner.
  • ncmncm 4y ago
    That is what we are all obliged to do already. It is a source of headaches and bugs. That is what is being asked to drop.
    • amenghra 4y ago
      Not really. Time smearing isn't moving the leap second into just a rendering thing.
      • ncmncm 4y ago
        Time smearing is its own bucket of nightmares.
• gmiller123456 4y ago
  For systems that leap seconds actually cause problems on, the solution is simply to use International Atomic Time (TAI) internally, and convert it to UTC when you want to display information to a user. Every time I see ditching leap seconds come up, they never try to explain why TAI won't work for them, leading me to believe they probably just don't know it exists, nor could they even imagine something like it being invented.
  • sunshi23 4y ago
    I need someone to explain to me why International Atomic Time = TAI but not IAT
    • jmole 4y ago
      The same reason the International System of units is referred to as SI, and not IS: the French.
    • layer8 4y ago
      For a similar reason why Universal Coordinated Time = UTC.
      • NovemberWhiskey 4y ago
        That one's even odder - that's the compromise between the English version, which would be CUT and the French version which would be TUC ... i.e. none of the above.
        • emmelaich 4y ago
          CUT and TUC are probably naughty words in some language. CUT is close the the Dutch kut.
          • layer8 4y ago
            TUC is a brand of crackers well-known in France, so maybe that’s why they didn’t insist on the French version. And CUT obviously didn’t make the cut. ;)
• benlivengood 4y ago
  The bigger problem is that UTC (and TAI) is defined in a gravity well so it's not going to be very useful in the long run. GPS has to correct its clocks to keep track of what we slow Cesium/Rubidium down to on the surface, and Voyager's clock is going even faster. We clearly want an Earth-centric time standard for wall clocks and that is UTC. The Earth is not a precision time-piece so we will always have to adjust our wall clocks to its rotation. Realistically, we should probably be deriving a time standard where every day has a slightly different length and we record the timestamps of the beginning of each day relative to a universal monotonic clock in a log (with rollups to years, centuries, etc.) that we keep around as long as anyone cares exactly how many Cesium vibrations have happened since $whence. If we want to actually solve the problem then let's switch to an interstellar time standard in a rest frame relative to the CMBR as far outside of gravity wells as possible and make that the universal monotonically increasing standard. Then computers can run on that time standard and UTC and friends can be derivatives.
  • Enginerrrd 4y ago
    I'm not sure it matters. To synchronize, you'll have to make corrections either way, and over sufficiently large scales, signal propagation delays are going to be quite large.
    • benlivengood 4y ago
      Here my physics knowledge gets a little sketchy, but if we have an accurate clock broadcasting on a known frequency somewhere far away we should be able to at least measure the drift between it and a local clock to arbitrary precision. With ~zero drift we can measure the distance and relative velocity very accurately with round-trip timing and Doppler measurements, and from that measure the clock offset as accurately as we can measure the distance. I think, but could be wrong, that we'd always be measuring the spacetime interval, not the euclidean distance in space, but that is probably what we actually want once we start caring about relativistic timekeeping.
  • Denvercoder9 4y ago
    > let's switch to an interstellar time standard in a rest frame relative to the CMBR as far outside of gravity wells as possible This won't work: since galaxies aren't static, and because the universe expands, the point with the highest gravitational potential ("as far outside of gravity wells as possible") will both move w.r.t. the CMBR and have a gravitional potential that changes over time.
• renewiltord 4y ago
  Is there a single change that can ever be proposed that would be considered worth it? I can only conclude that status quo bias is very strong among people. With this in mind, I can only conclude that Mark Zuckerburg is some kind of organizational genius with both his "move fast and break things" and his "move fast with stable infra" lines.
• j0057 4y ago
  Can we not just fix our systems to run in TAI or GPS time, and convert to UTC (or the user's local timezone) when displaying timestamps, instead of causing civil time to drift off indefinitely? I thought these were the best engineers in the world, go fix the computers then!
  • SoftTalker 4y ago
    This is the answer. Humans want noon to be when the sun is overhead, and midnight to be the middle of the night. Almost nobody cares about sub-second accuracy or monotonic time. Track it that way internally if you like, but humans want time to correlate to what they see out the window.
    • Ekaros 4y ago
      It seems there is increasing amount of people who actually want the sun be overhead at 13 and midnight to be at 1... Or even later... So, if we stop actually caring about normal time, why should we care about leap seconds either...
  • ncmncm 4y ago
    That is what everybody ends up doing, in practice. It is exactly the problem. Why should every software system everywhere have its own complicated, unpredictable, error-prone fudge that benefits literally nobody?
• throwawaytime99 4y ago
  If utc is causing problems with your calculations due to leap seconds than you should be using Unix time to do the calculations and then translating that to a human readable format. Imo society needs three distinct time counting systems. 1. Linux time. Essentially a universal addressing system for the measure of time in a agreed upon reference point (Earth’s surface). This should be the standard for science/computation, with the need for language to describe time dilation when comparing two reference points. Unix time doesn’t have leap seconds, or the concept of days. 2. UTC aka civil time. Things such as the orbit of the sun and the rotation of the earth aren’t in constant speed and don’t divide evenly with each other. UTC deals with short term variability with leap days and leap seconds. This is so every January 6th the earth is roughly in the same spot relative to the sun, and every 5pm the earth is in roughly the same part of its rotation. This is important because these things drift on human scale timelines. This calendar should be used for daily life, business, etc. 3. A purely astronomic calendar. A calendar that defines time by astronomic events. For example, defining a day as one rotation of Earth and not as a number of times an atom vibrates. This should be used so we can discuss astronomical events such as “A Martian year” or a “Saturn Day” and provide some meaning. This is the basics that should be taught to elementary school children to establish the cultural meaning of a day or a year and to provide some basic learnings of nature.
  • BoppreH 4y ago
    Unix time does have leap seconds. From Wikipedia: It is the number of seconds that have elapsed since the Unix epoch, excluding leap seconds. Yes, it means the Unix timestamp jumps around, either skipping or repeating a second, when there's a leap second. Yes, it is as stupid as it sounds.
    • cpcallen 4y ago
      I think this is the real problem. If we used a unix-time-including-leap-seconds instead then the date/time conversion functions would need to have a little extra smarts (a table of leap seconds in addition to a timezone database) but most of the leap second related problems would not exist. (We already deal just fine with months having variable numbers of days. Minutes having variable numbers of seconds is obviously awkwardly rare from a testing point of view, but not fundamentally more difficult to get correct.)
• layer8 4y ago
  A large part of the problem is that in software there is a traditional conflation of (a) time marks to measure elapsed time and (b) events where we want to know what their wall-clock date/time is. Those should in principle be kept separate. One can use a monotonic elapsed-time clock for the former and a calendar/wall-clock based clock for the latter. Conversion between the two shouldn’t be done gratuitously, and have to be done with the awareness that the mapping to future wall-clock dates (and sometimes also to past ones) is subject to change. APIs and data types reifying that distinction would be helpful.
  • ncmncm 4y ago
    I.e., add huge complexity to everything for no benefit to anyone.
    • layer8 4y ago
      As long as you have timezones that change over time, and e.g. DST changes, you have the complexity anyway. It is all simply an expression of the fact that (a) earth’s rotation and movement around the sun isn’t a steady clockwork with subsecond precision, and (b) timezones and calendars are a subject of political decision-making. It’s therefore just not possible to easily equate coordinates of civil time with physical time, and the related facilities in software development shouldn’t project an illusion to the contrary.
      • ncmncm 4y ago
        Geographic time zones are a completely separate matter. Dragging them in just muddies the water. The topic here is worldwide standard time, literally the same for everybody, and whether a million programs obliged to make tiny adjustments to it on a random, unpredictable schedule was a good idea. Anything fiddly and unpredictable a million programs have to get right will instead be got wrong.
    • thrown_22 4y ago
      This is the equivalent of complaining a foot is no longer my foot, but some kings.
• ajaimk 4y ago
  Engineers whining about having to do work that was designed in the past by someone else and coming up with a "creative" hack which will be a headache for someone in the future.
  • ncmncm 4y ago
    You wholly miss the point. A million programmers have to all, unanimously get a fiddly, hard to test detail right. Both those that do and those that don't get periodically out of sync with the other half, on a random schedule applied for no earthly purpose. Dropping any new leap seconds is choosing not to break a million systems, irregularly, to no purpose. No code needs to change. Things just stop breaking.
    • jackjeff 4y ago
      The hubris. If the definition of time is modified to match the buggy giant code base I don’t want to touch then I have no work to do. Genius! It’s akin to saying I want 2+2=5 because my code happens to work that way and it’s hard to fix. If FB hates leap seconds so much they can switch to TAI or Unix Epoch time. It’s not like UTC was modified to add leap seconds. It’s always been like that. It should not have come to them as a surprise.
      • ncmncm 4y ago
        Switching to something else puts them out of sync with everybody else who didn't. Same for anybody else. There is no possibility of "switching". Suggesting otherwise only proves you don't understand what this is even about.
• deleted 4y ago
  [deleted]
• Ericson2314 4y ago
  It's not just "legacy astronomical equipment". Humans like me want solar time = UTC + x for sake of e.g. scheduling meetings across time zones. It's embarrassing they can't figure out how to use the well accepted monotonic time solutions and are pulling this shit instead. Simple embarrassing.
• BrainVirus 4y ago
  I have a solution that no one will like, but it's probably the least insane one in practice. 1. We move from using leap seconds to leap minutes. 2. We move leap minutes to timezone offset, because time zones are already a clusterfuck and you can't make them any worse anyway. 3. One-time adjustment to all timezones to get the system started. Result: Z timezone is equivalent to TAI. When you want to account for planet-related BS, you apply a timezone offset. You can definitely criticize this, but with a caveat: if you believe that Unix timestamp doesn't have leap seconds or that timezones only come in 1-hour increments you clearly have no idea how computer time really works and should probably read up on that first.
  • layer8 4y ago
    It would probably even be okay to make the corrections only in whole-hour or half-hour steps, to avoid odd timezone offsets. The Brits however won’t like losing the 0-offset GMT.
    • lucb1e 4y ago
      Maybe it's more acceptable if the public is told they're likely to get it back at some undefined time in the future. (Or is that too soon after they severed EU relations only to immediately try and get those relations back in order?)
  • gowld 4y ago
    > if you believe that Unix timestamp doesn't have leap seconds If you have a source for leap seconds in Unix timestamp, please post a correction to Wikipedia. https://en.wikipedia.org/wiki/Unix_time https://en.wikipedia.org/wiki/Unix_time UTC has leap seconds, and so Unix time can be converted to UTC, for the era in which UTC-with-leap-seconds is defined (after ~1972)
  • lovecg 4y ago
    But why do we need leap anything at all? Leap years are useful because the calendar drifts quickly (well, over centuries) enough for seasons shifting to become noticeable. Leap seconds correct for a problem that’s much slower, with already existing much larger errors (time zones anyone?). It’s a science project with no useful application in the real world.
• gmiller123456 4y ago
  This periodic adjustment mainly benefits scientists and astronomers as it allows them to observe celestial bodies using UTC for most purposes This is incorrect, dealing with leap seconds is a major problem in astronomy, requiring a data file or even recompile any time there is a new one announced. Since they are only ever announced 6 months in advance, it creates a lot of logistical problems. Astronomy algorithms usually work in Barycentric Dynamic Time, or Terrestrial Time, or UT1. In reality the whole invention of UTC is so that people don't have to deal with those systems on a daily basis. The process most astronomy programs go through is to get the UTC from the user, convert the Gregorian date to a Julian day number to get rid of the Gregorian Calendar altogether. Then look up the number of leap seconds, add those to the JD to get International Atomic Time, then add 32.184 seconds to get Terrestrial Time. If Barycentric Dynamic Time is needed, you must first compute the velocity of the Earth relative to the solar system barycenter (which itself requires TDB), then compute the relativistic effects of that motion on Terrestrial Time. If you need UT1, these can only be obtained by observation from the International Earth Rotation Service, and required daily updates, and interpolation of values in between observations. So, as you can see, leap seconds do nothing to make an astronomer's life easier. In fact, we jump through a lot of hoops to make the average person's life easier. It sounds like Meta wants to change the definition of time for everyone just to make their programming a little easier. I find the very premise just out right ridiculous. It's true that your average person will not be affected by the Sun setting a few seconds earlier. But eventually it will build up enough error that it eventually has to be addressed, and Meta is just trying to make their problem someone else's problem.
  • exabrial 4y ago
    > Meta is just trying to make their problem someone else's problem. Business as usual
    • a9h74j 4y ago
      MAT -- Meta Adjusted Time. AFAIK 'mat' is also a [Sanskrit??] word for truth.
  • oconnor663 4y ago
• gumby 4y ago
  Strongly disagree. As the article itself points out, people who need it can already use TAI or UT1.
• deleted 4y ago
  [deleted]
• 6gvONxR4sf7o 4y ago
  In general, I hate when people doing people things gets replaced by bureaucracy doing bureaucracy things. Structure should support people, not the other way around. That includes time. If people want midnight (on their clocks) to match midnight (in their lives) or whatever, then the structure and code we put to it needs to support that. That includes changing things like time zones and calendars and leap years, and yes, leap seconds too. Just because we suck at codifying things doesn’t mean we should change the goal to make it easier to codify. If you need a more straightforward clock in your software, use just TAI or something, instead of trying to redefine calendars.
  • jefftk 4y ago
    Midnight on your clock is very likely tens of minutes or even hours offset from solar midnight, let alone seconds: http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV2.png http://blog.poormansmath.net/images/SolarTimeVsStandardTimeV...
• deleted 4y ago
  [deleted]
• aubergene 4y ago
  Whoever made that first line chart should have used step interpolation. There is no point in time when none integer amounts of seconds have been added, but it gives the impression it's been smeared over the whole year
• jefftk 4y ago
  Everyone is treating this as some idiosyncratic proposal of Facebook's, but removing leap seconds is a mainstream position. Representatives of the US, China, France, and a majority of other countries were in favor of this when it was discussed at the 2015 ITU meeting [1] though the UK and Russia's were not. This has been under discussion since at least the 2003 ITU meeting in Turin. [1] https://www.nature.com/articles/nature.2015.18855 https://www.nature.com/articles/nature.2015.18855
  • ncmncm 4y ago
    Yes. Leap seconds are just a thoroughly bad idea, from any angle. Yet, not nearly so bad as Google's approach: no leap, but a 24-hour smear, during which 24 hours they are out of sync with literally everybody else in the world.
    • joerichey 4y ago
      For future leap seconds, Google (including GCP) are planning to use a "standard" smear (https://developers.google.com/time/smear https://developers.google.com/time/smear). This is also the same smear used by AWS. It seems like if the ITU decides to keep the leap second (a bad idea, in my opinion), the large infrastructure providers will just use the same standard smear for their clocks.
      • ncmncm 4y ago
        They will be wrong all day long, not just for one second. AWS will be, too, evidently. Few others will do anything so idiotic.
        • guipsp 4y ago
          They will be wrong by at most one second. And being wrong doesn't even matter, as long as everyone (or rather, all your servers) agree.
          • fanf2 4y ago
• pbnjay 4y ago
  No mention that Go actually fixed the stdlib so that the code shown won’t have this issue again. Some discussion of the issue and the fix implemented start around here: https://github.com/golang/go/issues/12914#issuecomment-269933114 https://github.com/golang/go/issues/12914#issuecomment-26993...
  • ncmncm 4y ago
    Go cannot fix it in the library. It always leaks out.
• wyuenho 4y ago
  This post brings back horrors when I was trying to figure out from the logs why there was a sudden doubling of requests and orders on 2016-12-31:23:59:59. This is the time I learned that Linux does not distinguish the leap second from the second before it. This led me down to a rabbit hole of reading up on what the representation of a leap second was and found that there was none for Linux timestamp. Fortunately, this was in December 2019. I can only imagine the pain SREs had to suffer from on 2017's New Year's day on top of Cloudflare going down.
• barnabee 4y ago
  There is literally no aspect of society, science, or culture that I’m willing to buy into changing to make things easier for software developers and tech companies (or in fact any companies, but only tech companies seem to be arrogant enough to suggest it). What an entirely backwards way of looking at the world. If we can’t deal with IT that improperly models the universe, the right answer is not to change the world to be more like the shitty naive model the software implements, it is to be less dependent on the technology agreeing 100% with reality.
  • jefftk 4y ago
    It sounds like you would have been opposed to the introduction of timezones? They made everyone switch away from local solar time, primarily for the benefit of railway timetables.
    • nrvn 4y ago
      This is me. I want everyone to use UTC and align local lunch times to solar noons.
    • barnabee 4y ago
      I’m not particularly attached to time zones, so perhaps I would have opposed introducing them. Sticking with local solar time in the age of jet planes would have been at least as much fun as daylight saving time.
  • Beltalowda 4y ago
    But what benefit are leap seconds to "society, science, or culture"? I've never seen one. If the current drift would continue then we're talking about a drift of 9 minutes every millennium; less than an hour for all of recorded history (and it mostly likely won't continue as-is; sooner or later we'll get negative leap seconds).
    • barnabee 4y ago
      The current situation doesn’t need to benefit society to oppose changing it for Facebook. Society, science, and culture are not the result of some utilitarian optimisation function, and that is precisely the reason to oppose changing them simply to make some company’s engineering slightly easier (or even a lot easier).
• dclaw 4y ago
  Delete facebook.
• danielovichdk 4y ago
  "God" how I hate to work with time when programming. It's more difficult than pretty much everything else. Cache invalidation and naming does not come close imo.
• eftychis 4y ago
  It took Facebook/Meta only like ~20 years to figure out they shouldn't rely on time to keep things in sync? /s If you delve in distributed systems, I would be surprised if you never had the case of "hey 1/k of our computers think they are 1-2 hours behind in time. (because of NTP issues)" You could simply be working on a single computer and have to deal with time issues. (E.g. Local clock resetting to a prior date and system creating files timestamped earlier than older files.) I think the leap second is the most minor, not even worth mentioning problem. It is actually to our benefit, reminding us that (perceived) UTC is not a monotonic measure and computer time altogether is not. Computers nowadays adjust their time ~constantly. That they have to smear their leap second throughout multiple hours, and that computers having the wrong time leads to an outage (for a less than a second difference) troubles me honestly. What you are telling me is that next leap second we should all pray for Meta's NTP servers not going down??? Also: (if you are an fb engineer) What do you do with negative leap seconds? Speed things up...? (https://www.timeanddate.com/time/negative-leap-second.html https://www.timeanddate.com/time/negative-leap-second.html) The expectation is for a negative leap second coming up -- as the post does mention. This is an education problem if you expect that time intervals have to be strictly positive (or jump ahead). TL;DR: systems' should never use the wall clock to compute a time interval even if we get rid of leap seconds.
• mgaunard 4y ago
  Anyone doing precise timestamping uses TAI. Converting to UTC is easy when you need it. Meta's suggestion just shows how narrow-minded they are.
  • ncmncm 4y ago
    You have very evidently not thought it through, and are then accusing others of it.
    • mgaunard 4y ago
      "very evidently"? Where is this evidence that I haven't thought it through that you speak of? As I hinted, I'm sufficiently experienced with precise timestamping to know that TAI is the proper way there, and that "improving" UTC is not going to help. Their suggestion is that UTC should essentially be the same as TAI because there is code that makes incorrect assumptions about what UTC is. If you need a monotonic clock, there is already something for that. UTC is for the actual local time on Earth.
      • ncmncm 4y ago
        See? Called it.
• NovemberWhiskey 4y ago
  Next up from FB: about that whole "February has 29 days in a leap year" thing...
• mro_name 4y ago
  IMO it's time to leave fb in the past.
• bloak 4y ago
  This topic keeps coming up and I'm not sure I want to read all the comments just in case someone has written something that wasn't written last time it was discussed. Personally, I would like to keep leap seconds. The only change I would make is to demand a longer notice period: 18 months instead of 6 months would be good. Presumably that would mean we'd have to tolerate a slightly bigger difference between UTC and UT1 but that seems all right. It would be stupid and irresponsible to abolish leap seconds without deciding on and implementing an alternative way of keeping time, and therefore the calender, in phase with the cycle of daylight. There are alternatives (leap minutes, redefining the second, ...) but to me they all seem a lot worse than leap seconds. Of course, whatever we do in the future, software will still have to handle leap seconds for processing timestamps in the past so any change to the system would mean that most software gets more complex.
• makeworld 4y ago
  This article includes a Go code example: start := time.Now() // do something spent := time.Now().Sub(start) It's worth noting that the Go time library is specifically designed so that computer clocks running backwards won't cause `spent` to be a negative duration. A monotonic clock that only ticks forward is used for time comparison and subtractions. Source: https://pkg.go.dev/time#hdr-Monotonic_Clocks https://pkg.go.dev/time#hdr-Monotonic_Clocks
  • klabb3 4y ago
    Hehe, story time: I was using exactly this logic to detect hibernation/sleep, especially for laptops. I was surprised when it never triggered, and printed the time, which indeed showed that a long time had passed. So why didn't it trigger? Because IFF both time stamps have monotonic component (internal, not visible on print) then the monotonic stamp is used. Confused me a lot. One man's bug is another man's feature.
• bakul 4y ago
  Wouldn't it be less of a disruption if we standardize how smearing is done?
  • ncmncm 4y ago
    Smearing is overwhelmingly more disruptive than anything else that has been done.
• Matthias247 4y ago
  > As already mentioned, the smearing is a very sensitive moment. If the NTP server is restarted during this period, we will likely end up with either “old” or “new” time, which may propagate to the clients and lead to an outage. That seems to be a solvable engineering problem. One could make sure the server is up to date on all recent information before taking it back into service. It's a similar problem as making sure that cache servers that have invalidated data don't go back into service before their cache is updated - which is tablestakes for services like CDNs. I guess the problem here are public servers that can't run software that understands doing that? I see the challenge for those, but maybe something like an improved version of NTP could fix it?
• Balgair 4y ago
  >Leap second events have caused issues across the industry and continue to present many risks. As an industry, we bump into problems whenever a leap second is introduced. And because it’s such a rare event, it devastates the community every time it happens. With a growing demand for clock precision across all industries, the leap second is now causing more damage than good, resulting in disturbances and outages. Translation: We suck at computers and think you all do too. So let's just bury our head in the sand and make some cash before it all falls down. I'm being glib, but come on guys. You're trying to tell me that your crummy programming and cash flow is more important than the literal spinning of the Earth. You can try all you want, but the sun will set when it does, your clock be damned. I may be a rare person on HN that actually has dealt with these leaps from the 'source'. I used to work for a pico-second accurate timing company and had to go through the microsecond adjustment due to the March 11th, 2011 earthquake in Japan. The company was a backup site for the NIST clocks. I've even worked with the second at NIST. Yes, that little port at about eye level that the whole US uses as it's second. You can't take things out of the room (like asbestos) and you can only be in there for short periods, it's that sensitive and important. All that said, the Earth is a really crummy clock! But guess what? You can't fix that. It's mother nature's world and we just live on it. If FB thinks that trying to get everyone to quite literally 'not look up' is going to work in the long term, they are in for even more headaches than they already have. Many, many industries and sectors must use hyper precise clocks and they must be aligned with the Earth's rotation. If are not, then they will drift psuedo-randomly apart as all clocks do. And then you're screwed when you try to get your own little clock system to talk to other clock systems that have been drifting too. You think you have issues now with imagined negative leap seconds? Wait until you try to define time.
• deleted 4y ago
  [deleted]
• exabrial 4y ago
  Which isn't why we created to Unix Epoch anyway? The number of seconds since an arbitrary event, with no regard of the movement of celestial bodies? And isn't Unix Epoch derived from some sort of Atomic clock standard? I can't remember, but it seems all of our systems time should be atomic time, then you can derive UTC or whatever you want from that.
• tene 4y ago
  If they don't want to bother with leap seconds, why are they even using UTC? Why can't they just use TAI instead?
• deleted 4y ago
  [deleted]
• Asmod4n 4y ago
  Will satnav become unusable when leap seconds get abolished?
  • ncmncm 4y ago
    No. GPS (which I assume you mean) is already based on TAI.
• ForHackernews 4y ago
  Counterproposal: Facebook turns off their servers during the next leap second.
  • jackjeff 4y ago
    I second that. I suggest they don’t then them back on. Eventually a startup who can deal with either TAI or leap seconds will take their place.
• notacoward 4y ago
  FWIW, Facebook did not use UTC when I was there. They used Pacific time everywhere, which was even worse. And half of the internal tools would convert to local time but the other half wouldn't. I just kept my work machine in Pacific time even though I'm in Eastern, so that compiling incident timelines (for example) would be less tedious and error-prone.
• poppafuze 4y ago
  Meta has it backwards, because they could've already made another choice. UTC is a representation of the offset. This will always need to be calculated somewhere. Much like how the GPS counts the time since the epoch and broadcasts the offset...it can be used or not by the user. Those times are a calibration adjustment. For UTC, that adjustment is a reference to the current status provided by IERS. That's literally the job of UTC. Meta can simply stop applying a time offset in their reference, use TAI for forensics, and then have a separately calculated time when they need to display in that representation. ...Which is what happens already. System time is seconds since The Unix Epoch. All of those times are calculated and available, and always will be. They chose one of them, didn't like it, and invented a crummy workaround. They could've logged it in TAI and appended the TAI TZ to all their timestamps. This is being done to work around poor coding choices they made, instead of making the computing fit reality. Basically "We chose smearing, which is a poopstain of tech debt, so we'll fix it by telling the whole world what time it is." That request is loaded with colossal hubris. They might as well have the second redefined. The real operators do their thing and leave the squawking to those who want to self-identify a poor coders. Because if they don't want to account for a clock that jumps, then they're kicking the can down the road and they want everyone else to join. Turning it into a Y2K or Y2038 problem is a sad choice of saddling bigger tech debt on the rest of the world. Calling it mainstream is as much of a narrative as permanent daylight savings time was. The software solutions exist and were deployed (at least throughout Linux and main userspace) by the June 2015 leap. This is a Facebook problem that they're sloppily handling by pushing it on literally everyone else.
  • nullc 4y ago
    Leapseconds are an everyone problem. You've personally been impacted by disruptions from leapseconds though you might not be aware of it: it's often not even mentioned in coverage the the cause of issues were leap seconds. E.g. https://insidegnss.com/u-s-flights-canceled-as-faa-looks-into-gps-ads-b-system-errors/ https://insidegnss.com/u-s-flights-canceled-as-faa-looks-int... How many times have you had an issue and resolved it by restarting a system or service without ever truly figuring out the cause?
    • 4y ago
• deleted 4y ago
  [deleted]
• neuronexmachina 4y ago
  This article mentions some of the others who are part of the effort: https://www.cnet.com/tech/computing/tech-giants-try-banishing-the-leap-second-to-stop-internet-crashes/ https://www.cnet.com/tech/computing/tech-giants-try-banishin... > Google, Microsoft, Meta and Amazon launched a public effort Monday to scrap the leap second, an occasional extra tick that keeps clocks in sync with the Earth's actual rotation. US and French timekeeping authorities concur. > ... The tech giants and two key agencies agree that it's time to ditch the leap second. Those are the US National Institute of Standards and Technology (NIST) and its French equivalent, the Bureau International de Poids et Mesures (BIPM).
• eternityforest 4y ago
  What if we drop leap seconds completely, but for display and input, we use continuous interpolation, with factors published every year, a year in advance(So that mostly offline devices stay accurate) Imaginary civil days would always have exactly 3600×24 seconds. We could always convert any past date easily with a small table. We could convert any future date with reasonable accuracy just based on extrapolation. No ambiguity, no jumps, we still stay roughly in sync. We could even just use 10 year blocks so that in the short term, most projects would have the entire future conversion factor timeline known at the start.
• hramrach 4y ago
  Has anybody actually read the article? Meta is not arguing against adding the leap second, they just argue that skewing the clock slightly over some hours avoids the 'invalid' time with 61 seconds in a minute and the resulting software problems while keeping the time reasonably accurate for for the general public and computer systems.
• XorNot 4y ago
  Absolutely nothing prevents Meta and the other big boys from sponsoring a time standard they like for their internal systems, or just using one of the existing ones which doesn't have them. Recode your APIs to emit that standard, if you have to still use GPS time then build a box which syncs to GPS and deletes leap seconds (of course why? You can buy rack mounted atomic clocks these days which will stay perfectly accurate for hundreds of years). This is, in every way, not a problem they have to cooperate with anyone else about. EDIT: also, Unix Epoch Time, has never had leap seconds. The standard is defined as UTC exactly at the start of the Unix Epoch and ticks at 1 second since then. So from that perspective, and the perspective of every sensible internal clock system in programming, you already don't have a problem.
  • XorNot 4y ago
    Self-reply: my edit is actually wrong - in practice Unix time is implemented with leap seconds on leap-second days and doesn't drift from UTC.
• andrewprock 4y ago
  Doing away with leap seconds does not solve the problem. It only transforms it into a different problem. It's addressing the same problem that February 29th speaks to. You can do away with leap seconds, and you can do away with February 29th. But doing so with change the fact that the length of a year is not a while number of days, nor will it change the fact that the length of the year is non-stationary.
• dudeinjapan 4y ago
  Can we get rid of timezones while we're at it?
• mdavis6890 4y ago
  I’m reminded of the most excellent write-up on qntm.org about abolishing time zones. If you haven’t read it, and you’re one of those kinds of folks (I was!) this will quickly sober you up :-) https://qntm.org/abolish https://qntm.org/abolish Also, Chesterton’s Fence.
• hgsgm 4y ago
• beloch 4y ago
  I'm almost surprised that, after explaining conservation of angular momentum, they didn't propose a bonkers solution like building a pipeline from the sea up a mountain to create a massive artificial glacier to directly regulate the Earth's angular velocity. It's bonkers, but so is just asking metrologists to stop being so darned concerned with accuracy of time measurement because its causing Facebook to spend money they'd prefer not to spend.
• Wolfenstein98k 4y ago
  Fantastically written article, well-argued and clear.
• heynowheynow 4y ago
  Never gonna happen because there are competing vital interests: 0. Human diurnal local time 1. Universal time similar to 0. but without local offsets - UTC (UT1) 2. Universal monotonic time (within comparable gravitational reference zones) - TAI These already exist. There is nothing to add or remove, but to do things differently that have already been recommended rather than sticking with insane traditions for another 25 years wherever possible. UTC (UTn), GMT, are insane for timestampping. Use TAI essentially everywhere and calculate it later as UT1 or local time. If you fail to do so, you risk discontinuities and security vulnerabilities. This is why you should and must use TAI64[N[A]] rather than UTC because UTC is not monotonic. You can get UT1 from TAI by downloading LS tables and doing the math yourself. It is rare to find UTC-centric code implemented correctly. This isn't rocket science, it's first principles of recording data that doesn't vary nondeterministically in forward time.
• jackjeff 4y ago
  It’s time for FB to adopt TAI or UT1 and stop moaning. Wtf is this attitude of modifying the definition of time to fit your engineering needs where there’s a perfectly available alternative quoted in the article. I really don’t get it. If you don’t like leap seconds use a definition of time that does not have them. Why modify the only standard with leap seconds and annoy everybody else?
• graderjs 4y ago
  From [this]: This creates a fundamental problem. It is now universally agreed that atomic clocks provide a much better measure of time than does the Earth's rotation, yet for human comfort, we would still like time to stay in sync with the Earth's rotation. How to accomplish this? Can't we just bifurcate? Machine time and human time. [that]: https://mperdikeas.github.io/utc-vs-ut1-time.html https://mperdikeas.github.io/utc-vs-ut1-time.html
• BiteCode_dev 4y ago
  I believe twitter's QNTM said it best: "Facebook developers are apparently so frightened of a negative leap second that they think altering the way global timekeeping works is easier than fixing their code"
• gorgoiler 4y ago
  This article makes the claim that the calculation of elapsed time is impacted by leap seconds, to the extent that the following value of “elapsed” may even be negative: t0 = time.now() /* do stuff */ t1 = time.now() elapsed = t1 - t0 This is not correct. Leap seconds are only the concern of how to render time in a human readable way. System time itself always passes one second at a time, and calls to time.now() interspersed with sleep(1) will always go up by one second at a time. It’s just that at some times of year we render that as 23:59:60 and some times we don’t. But perhaps clock smearing is genuinely changing the way systems measure time, as opposed to smearing how the system renders t=1658818054.0 as hours, minutes and seconds? That seems implausibly incorrect. Lining up the minute hand with the noonday sun on one particular part of the planet should not possibly have any impact on measuring how long it takes to compile my code.
  • twic 4y ago
    If your clock is perfectly synchronised to UTC, then this is not true. Two calls to time.now() one second apart will sometimes return the same value - the same count of seconds elapsed. Here's what POSIX has to say [1]: > 4.16 Seconds Since the Epoch > A value that approximates the number of seconds that have elapsed since the Epoch. A Coordinated Universal Time name (specified in terms of seconds (tm_sec), minutes (tm_min), hours (tm_hour), days since January 1 of the year (tm_yday), and calendar year minus 1900 (tm_year)) is related to a time represented as seconds since the Epoch, according to the expression below. > If the year is <1970 or the value is negative, the relationship is undefined. If the year is >=1970 and the value is non-negative, the value is related to a Coordinated Universal Time name according to the C-language expression, where tm_sec, tm_min, tm_hour, tm_yday, and tm_year are all integer types: > tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 > The relationship between the actual time of day and the current value for seconds since the Epoch is unspecified. > How any changes to the value of seconds since the Epoch are made to align to a desired relationship with the current actual time is implementation-defined. As represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds. > Note: > The last three terms of the expression add in a day for each year that follows a leap year starting with the first leap year since the Epoch. The first term adds a day every 4 years starting in 1973, the second subtracts a day back out every 100 years starting in 2001, and the third adds a day back in every 400 years starting in 2001. The divisions in the formula are integer divisions; that is, the remainder is discarded leaving only the integer quotient. The key point to hang on to is that in POSIX "seconds since the epoch", a day is always 86400 seconds long, and midnight in GMT is always an exact multiple of 86400 - and so the value of "seconds since the epoch" must necessarily be bodged to account for leap seconds. It is not a monotonic, linear measurement of the passage of time. Another angle on this is to look at any date and time library you fancy. To convert from linear seconds-since-the-epoch time to a human-readable timestamp, they would have to obtain a leap second correction from somewhere, and apply it before doing formatting. There is no date and time library which does this. Because they all expect a nonlinear, UTC-aligned seconds-since-the-epoch. [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_16 https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...
• SonOfLilit 4y ago
  I'm really confused by the common complaint in this thread about the arrogance of programmers wanting to change time for everyone else to make it simpler for themselves. No, in today's world time is a programmers' problem. Nobody except programmers (and some very technical software product managers, e.g. astronomers) needs to deal with time issues like these. Who builds systems that need to be synchronized to the microsecond level or more? Programmers. Who makes calendar software that should support timezones and DST correctly? Programmers. Who runs astronomy calculations that really care about UT1? Programmers working for astronomers. Every time someone has an issue that requires very delicate handling of time, there is a programmer implementing the solution. So of course it would be a group of the largest software companies, responsible for software like Outlook and GCal and public clouds, who would get together to say "listen, world, this leap second thing is more trouble than it's worth, how about we just stop fiddling with it?" They're the people responsible for implementing everyone else's time handling requirements. I think we should listen to them. Another confusing argument here is "let them just move from UTC to TAI, and thus move leap seconds to be a display issue, like timezone best practice". In a vacuum, this could have been a great solution. But we live in a world where almost all computer software already written is based on UNIX Epoch Time, which is defined as tweakable by the leap second committee, and the breakage usually occurs either in existing software or in sync issues between new software written at Meta or MS or wherever and existing software, so moving all their centrally managed systems to TAI while leaving us programmers of the less hierarchical outside world to keep suffering wouldn't solve much, and also wouldn't be very nice. Kind of an https://xkcd.com/927 https://xkcd.com/927 situation. Instead, they're writing a letter saying "dear leap second committee, we are your largest users and our use case is representative of everyone else's, can you please stop fiddling with the standard agreed time, it's causing problems for everyone. You can get the same effect by twiddling with display time (timezones), which we already have to support anyway and is much easier to test." My favorite design principle is the Representable/Valid principle: your representation/model of the world should have one way to represent each valid state, and should not have ways to represent invalid states. Lets get together as a species and refactor our model of time to have one less case of two states having the same representation! I for one welcome our new monotonic timelords.
• notorandit 4y ago
  You want to leave it because you cannot cope with it. time.google.com can.
• drchaim 4y ago
  I would like to understand all of this. :)
• Schroedingersat 4y ago
  Counter-proposal: Get rid of leap seconds but move all the time zones a few metres every year.
• sylware 4y ago
  LOL, I was sure that the UTC had no leap seconds which were exclusive to calendar date and time calculations. If true, oooooh goooood! I agree with big tech on this one. Redefine the UTC starting point at the last 17th update and be done with it.
  • sylware 4y ago
    wait, I was thinking the unix time.
• Unklejoe 4y ago
  I'm shocked to see people here arguing for keeping leap seconds, accusing the Meta engineers of just being lazy. Leap seconds are stupid in my opinion. Under no circumstances should a timescale have discontinuities like that.
• fdsjgfklsfd 4y ago
  So because Facebook engineers can't write good code, the whole rest of the world should change our conception of time?