14 ms·

All I want for Christmas is a negative leap second

196 points by NKosmatos 2y ago

k310 2y ago
There is no mention of the affect this might have on investing or wagering. Or is the author keeping that close to the vest?
- techdragon 2y ago
  They don’t care about that. I mean it’s the opening paragraph… > I just want to see it. Just once. I want to watch that earthquake ripple through all of global electronic timekeeping. I want to see which organisations make it to January morning with nothing on fire.
  - uoaei 2y ago
    Seems like a good dry run for redundancy/resiliency tests in the face of more catastrophic failures such as those that can result from solar storms.
- danpalmer 2y ago
  I agree with the author in finding some amusement in such trivial (in context) matters falling in the face of a phenomenon as fundamental as the planet's spin, something humans will likely never make a dent in.
  - lovecg 2y ago
    Don’t give them any ideas! If I know humans, they’re the kind of species to figure out how to extract energy from the Earth’s rotation, overdo it way too much, and then deny that they’re the ones responsible.
    - maxbond 2y ago
      See also: > Tidal Energy Is Not Renewable > It is incorrect to consider tidal power as renewable energy. Harnessing tidal energy will pose more severe problems than using fossil fuels. ... Tides are induced by the rotation of the Earth with respect to the gravity of the Moon and Sun. The rotational energy of the Earth is naturally dissipated by tides slowly. Consuming tidal energy further reduces the rotational energy, accelerates the energy loss rate, and decelerates the rotation of the Earth. https://cs.stanford.edu/people/zjl/pdf/tide.pdf https://cs.stanford.edu/people/zjl/pdf/tide.pdf (I've not evaluated these claims in detail, I just thought you may be interested.)
      - mtoner23 2y ago
        It's completely wrong. He assumes energy will increase exponentially into the future to get to his wild claim that we could tidally lock to the moon in 1000 years. Even solar power out nuclear could not power humanity in that scenario
        maxbond 2y ago
        Certainly if we grow exponentially for a further 1000 years we'll exceed the carrying capacity of this planet, however we derive our energy. I don't think that's a very interesting result. By "completely wrong" do you contend that using tidal energy doesn't decelerate the Earth's rotation?
        pas 2y ago
        Can we even change viscosity meaningfully? (Coastlines already form natural "dams". All we would do is move the coastline inward a bit, so as the tide flows through it it spins turbines. The water gets moved the same. The energy is already dissipated at the coasts, it would happen at the dams. Total dissipated energy is the same this way. Okay, if we start putting 4 km tall dams in the middle of the ocean we might somehow meaningfully change the viscosity.) The thesis in the PDF seems to be that somehow we can push the brakes more. Maybe. (So if we let the Sun/Moon grab some water then use the Earth to get it moving again, then it necessarily slows down the rotation. But there's already a lot of energy in moving and compressing water itself, sure it's "uncompressible" compared to gases, but there's plenty of molecular stuff to move around where energy can go. There's some tidal heating too.) It's verbose, but in a bad way, and it's structured in a way that makes it hard to comprehend. (And the whole pro-fossil-fuel framing is just .. huh.)
- htthbjk 2y ago
  [dead]
hirsin 2y ago
I feel like we'll get a (less physically _real_, but much more impactful) run of this "make it to the next day unscathed" adventure in 2038. Only 14 short years...
Dylan16807 2y ago
On leap minutes: > Because there's nothing computer programmers handle better than special cases which only occur every hundred years or so. How in the world could this be an improvement? If it's less than 60 times as disruptive, it's an improvement. > everybody's going to hate it at least sixty times as much as they hate leap seconds now I doubt that. > If something is difficult, you do it more often. It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain. > But before 1972 UTC and TAI were kept in much closer synchronisation [...] (No, I'm not advocating returning to this state of affairs.) Coward! But seriously, I think this hurts the previous argument significantly.
- lmm 2y ago
  > It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain. Yeah, if we're not going to abolish leap everything in UTC completely (which I think we should) then leaps need to happen at most quarterly. When the last leap second came through it was long enough since the one before that the bugs in Linux had been fixed and then unfixed.
  - marcus_holmes 2y ago
    Do we introduce an unnecessary leap second and then negative leap second every year just to keep the gears oiled? And then if we need one for reals we can increase it to two leap seconds added and only one removed. Though of course that will cause bugs in any code that isn't expecting two leap seconds to be added and assumed that there would only ever be one. sigh
    - bee_rider 2y ago
      We could build it into daylight savings time. Instead of jumping an hour, we announce what the jump will be every year.
      - 2y ago
rblatz 2y ago
So my assumption was that Unix timestamps were monotonically increasing and that for the case of leap seconds the conversion from timestamp to UTC would take those into account and for some seconds have 2 mappings. That would keep the ordering of events, it would break assumptions like a day is 86400 seconds. But I guess they decided to keep that invariant, which makes negative leap seconds really hard. Maybe that’s a good trade off.
- marcosdumay 2y ago
  Unix keeps the 86400 seconds as an invariant, and ignores the IS size of a second. This should work just fine for negative leap seconds too, you just make your seconds shorter instead of longer. Of course, it's a near certainty that it won't work just fine. But it should.
- kibwen 2y ago
  The Rust standard library, which provides an API for monotonic timestamps, used to contain this silly hack (with appropriately exasperated comment) because in practice so many platforms and CPUs (Linux, Windows, BSD, x86, x64, Arm) failed to provide monotonicity despite their own documentation: https://github.com/rust-lang/rust/blob/80184183ba0a53aa4f491753de9502acd3d6920c/library/std/src/time.rs#L223-L250 https://github.com/rust-lang/rust/blob/80184183ba0a53aa4f491...
  - zaptrem 2y ago
    // It seems that this just happens a lot in the wild. // We're seeing panics across various platforms where consecutive calls // to `Instant::now`, such as via the `elapsed` function, are panicking // as they're going backwards. Placed here is a last-ditch effort to try // to fix things up. We keep a global "latest now" instance which is // returned instead of what the OS says if the OS goes backwards. // // To hopefully mitigate the impact of this, a few platforms are // excluded as "these at least haven't gone backwards yet". Why exclude any platforms, just in case they start going backwards for whatever reason?
    - 2y ago
ooterness 2y ago
I have never understood why POSIX and NTP timescales work the way they do. They are positively bonkers when it comes to leap seconds. Time isn't even monotonic during the transition, because the epoch itself is redefined. Contrast this with the GPS or PTP timescales, which simply count seconds since a well-defined epoch. Formatting the date and time for humans to read is a sensibly separate process.
- tverbeure 2y ago
  But then GPS went off the rails and used a 10-bit number for count weeks, resulting in the 19-year week number roll-over (WNRO) problem. A few bits more would have solved a lot of problems.. Ref: https://en.wikipedia.org/wiki/GPS_week_number_rollover https://en.wikipedia.org/wiki/GPS_week_number_rollover
  - cbhl 2y ago
    Given that the first GPS satellites were launched in 1978, saving a few bits was standard practice at the time -- bits were expensive. Code of the time also often had two-digit years (the infamous Y2K problem).
    - tverbeure 2y ago
      A full GPS navigation message is 37500 bits. I'll admit that it's not that simple: there are repeating fields in that message to avoid having to 12.5 minutes between each update. They could have kept the week number in the repeating message at 10 bits while having a non-repeating MSB?
      - akira2501 2y ago
        It's 1500. The full data set is 37500 but you get there by spreading the larger message across several subframes. The full data set includes ephemeris data for all other satellites. It's precisely as long as it needs to be. This also means there is a built in fixed maximum number of satellites in constellation. The time code gets 300 bits. It lasts 6 seconds and it's repeated every 30 seconds. Critically, it will always occur precisely on the top (:00 seconds) of the minute, or the bottom (:30 seconds) of the minute. Interestingly, most of the time code is used for /correction/ parameters, as precise values for these are required to accurately calculate time. Satellites themselves drift in performance as they age so these parameters are not static for the lifetime of the deployment. If you want to get into the nitty gritty, again, made in the 70s, so it's pretty approachable today: https://www.gps.gov/technical/ps/1995-SPS-signal-specification.pdf https://www.gps.gov/technical/ps/1995-SPS-signal-specificati...
samplatt 2y ago
qntm, I know you're reading this. As someone working on software that works on ships (aka, software that needs to change timezones and locations often and still maintain contiguous millisecond accuracy of all shipboard equipment events), this article has caused me significant psychological damage. There Is No AntiTimekeeping Division ...
- pas 2y ago
  > still maintain contiguous millisecond accuracy of all shipboard equipment events can you elaborate on the purpose of this? is it for legal requirements? some kind of "black box" recorder? why does timezone matter for such low-level event data?
  - samplatt 2y ago
    Naval boats cost a fortune. The telemetry from the onboard engines/machines/computers needs to be in sync, and they don't always have compatible timekeeping systems, so sometimes it needs to be translated into a common format and recorded in our db's. If something goes wrong, a lot of parties both internal and external are interested in reviewing the (extremely detailed) logs for the purposes of insurance, or court-martial, or whatever.
theptip 2y ago
Riffing on “if it’s painful, do it more often”, I wonder if mandatory leap seconds every year, but trueing up the delta from N years ago, would be a good compromise? Regularity makes it easier to plan, and 6 months’ notice is not really enough for many OS distribution paths (eg IoT, embedded). Since the list of delta updates is queued, you could bake N years of updates into your system if it’s a fire-and-forget OS. A number in between 5 and 10 seems reasonable to me, but seeing as we are discussing living with 50 years of drift it could be higher. And sure, for this to work, allow non-integer deltas again; or just have a rule that you round the applied adjustment down. Seems no harder to bake in the last 50 years of leap seconds as to include to Olson TZ database in your distro.
- lifthrasiir 2y ago
  That's actually a good idea in the short term (i.e. less than one century). The length of the day (LOD) is thought to be linearly increasing in the long term though, so ΔT, the cumulative difference between past SI days and actual LOD, should be quadratically increasing and a delayed leap second adjustment would be too slow to catch up at some point in the future. Yet another possibility is to put any possible kind of leap second at the beginning of the year. The only requirement set by past CGPMs is that dUTC = UT1 - UTC should be in [-0.9, +0.9] seconds, so we can always put a positive leap second when dUTC is in [-0.9, -0.1]s and a negative leap second when dUTC is in [+0.1, +0.9]s, dramatically increasing the number of leap seconds without violating the dUTC requirement. If the dUTC requirement is a bit more relaxed (say, [-2, +2] seconds) then we can even mandate leap second every year! But well no, I'm strongly against the current form of leap seconds because it is already problematic in the short term and will be yet useless in the long term. Recall that ΔT is expected to be quadratically increasing in the long term; this means that the effectiveness of leap seconds is limited to the point when any small fixed number of leap seconds per year (12 in the current system, but anything larger than 1 will cause a problem) is no longer sufficient, and that point is not far from the point where the magnitude of ΔT is significantly large and leap seconds are absolutely required. As DST demonstrates, the world is probably fine with ~2,000 seconds of ΔT, which wouldn't happen before 2500, but at that point we would already start using double leap seconds per year at average. We would probably abolish leap seconds for that reason alone.
modeless 2y ago
I think it's weird how people react with such horror to the idea that maybe, just maybe, it wouldn't represent any kind of problem to the people of the 23rd century if 12:00 didn't correspond to the instant the sun was directly overhead, but instead a minute past. Nor would it cause any issue for people thousands of years from now if 12:00 was in the evening or the morning or any other part of the day or night. For those future people it would simply be the way things are, and it would stay that way their whole lives.
- mjevans 2y ago
  Noon already does not correspond to the sun overhead. Timezones, and IIRC the time of year and inclination relative to the equator matter too. However, irrespectively, it's basically never solar noon at noon if someone is using time zones rather than local solar time, which of course would be a custom timezone for that exact location.
  - sfilmeyer 2y ago
    This article that I just came across does a nice job at explaining some of the nuances of solar noon https://www.timeanddate.com/astronomy/solar-noon.html https://www.timeanddate.com/astronomy/solar-noon.html . The time of year does matter a bit, but the effect is smaller than the effect of timezones. Their equation of time article includes a nice graph of the variations in time of solar noon at Greenwich. https://www.timeanddate.com/astronomy/equation-of-time.html https://www.timeanddate.com/astronomy/equation-of-time.html
    - Izkata 2y ago
      > This article that I just came across does a nice job at explaining some of the nuances of solar noon https://www.timeanddate.com/astronomy/solar-noon.html https://www.timeanddate.com/astronomy/solar-noon.html . And a related thing, the analemma - the sun's position at the same place on earth at solar noon over the course of a year doesn't resemble an arc, it's a figure-8: https://en.wikipedia.org/wiki/Analemma https://en.wikipedia.org/wiki/Analemma
- 2y ago
ikekkdcjkfke 2y ago
If I am asking for how many seconds since 1970, I'm literally asking for that, as if someone stood with a stopwatch (not a cellphone clock!) How you want to display that in various timezones i do not care
- defrost 2y ago
  Which specific stopwatch? Why don't you care about that stopwatch's drift over the past 50 years, the tempreture related variation, the errors induced by motion, air pressure and humidity? Would you prefer a count that's averaged over many from the same manufacturer, or from many over many manufacturers?
  - 01HNNWZ0MV43FF 2y ago
    Switch to TAI + fixed offset I just don't give a damn whether solar time is a couple minutes off of calendar time. Seconds should be seconds. Solar time is a human construct, it shouldn't affect computers.
    - defrost 2y ago
      The person I responded to was interested in 50 years of seconds from a stopwatch. That's a mechanical device with multiple sources of error and a need to be wound regularly. The questions I asked are about common sources of drift in mechanical watches and wether or not they cared enough to attempt to account for them.
      - icehawk 2y ago
        You're conflating the term "stopwatch" with an all mechanical device. That wasn't even true at the time period specified-- the quartz movement had been created in the 1950s and the first quartz pocket watch had been introduced in the mid 1960s. The issues you bring up are only relevant to a particular set of devices that can be used as timepieces that measure the amount of time that elapses between its activation and deactivation-- and are are all stopwatches.
_ache_ 2y ago
I don't understand that someone just want chaos. I guess "Some people just want to watch the world burn". But negative leap second shouldn't be so noticeable since it will just be a jump from 31 dec 23:58 to 1 jan 00:00. Facebook made a lot of FUD about a negative leap second but I don't think it should be THAT a concern.
maxglute 2y ago
Always facinated by how complex standardizing timekeeping is. If here was a chance for a global redo, would there be a more simplified system?
- htthbjk 2y ago
  [dead]
- akira2501 2y ago
  Almost certainly not. The problem time keeping is meant to solve is coordination of physical movements between separated parties that have exceptionally limited and delayed communication capabilities. All of the time issues we deal with today are in service of keeping these important properties of our civil time in tact. In terms of computers we should happily ignore the problems of civil time, simply just use TAI, and use a provided database to convert this into "human display time" whenever necessary.
  - School-Cotton 2y ago
    Leap seconds do absolutely nothing to fix the problems you’re talking about, for anyone. If we had never invented UTC and used TAI (+ time zone offsets) for civil time, the fact that civil time is drifting away from solar time on the order of a minute a century or so would at most be an obscure curiosity.
    - akira2501 2y ago
      The question was about historical time keeping in general, not about leap seconds specifically, so I'm not sure what point you're trying to make here. Also, astronomers care about leap seconds, and astronomy is an important tool in making observations which lead to predictions about our universe, so I wouldn't be so cavalier in labeling it an "obscure curiosity."
      - School-Cotton 2y ago
        I'm pretty sure astronomers don't care about leap seconds, and use more precise/fit-for-purpose tools.
etx 2y ago
[dead]
diego_sandoval 2y ago
Leap seconds are an extremely Earth-centric concept.
- Ekaros 2y ago
  Sometimes I have wondered is there proper write up of how messy intragalactic or intergalactic communications and time keeping would be. With or without FTL communication... Relativistic effects could actually be significant. Not to mention different rotation rates, day lengths, month lengths and so on... Leap seconds are comparatively simple problem...
  - gpvos 2y ago
    They're considering creating a new time standard for the Moon. https://news.ycombinator.com/item?id=39916102 https://news.ycombinator.com/item?id=39916102
- akira2501 2y ago
  Yea, unfortunately, all of our really good telescopes are bolted to it.
  - kibwen 2y ago
    JWST lives in the Earth-Sun L2 point, so I suppose that's still technically true.
knorker 2y ago
Negative leap seconds seem like they shouldn't be much of a problem. At least they don't involve repeating a second. No queries came in during a whole second? Who cares?
- dark-star 2y ago
  Yeah I'm wondering about that too. I don't think it could possibly be worse than having times like "23:59:60" pop up anywhere and messing every parser or regex up. It would just be like "huh, nothing bad (or good) happened during 23:59:58 and 0:00 according to our logfiles"
- zokier 2y ago
  Negative leap seconds will mean that there will be UNIX timestamp value that is invalid. What should systems do when they encounter such value? Generally UNIX time -> UTC conversion is considered to be infallible, negative leap changes that.
  - knorker 2y ago
    Sure, in theory the string 20xx-12-31T23:59:59 should never be created. But if it is created, so what? A time span is off by a second, in the positive direction. Not good, but shrug. I'm not saying it's a good thing. At time recording it's like the computer froze for a second. Compare this to the problem of there being a unix timestamp integer that refers to two different times, which is what naive positive leap second implementations resulted in. Real time spans being impossibly negative. Positive leap seconds are orders of magnitude worse. Unless you're writing time keeping software, negative leap seconds can be ignored and will be "just fine". And if you are writing time keeping or benchmarking software, then this is just another thing to not have a misconception about. > Generally UNIX time -> UTC conversion is considered to be infallible And generally there's two seconds between N and N+2.
  - zzo38computer 2y ago
    Normally, nothing. The invalid UNIX timestamp can still be converted to a (also invalid) UTC timestamp, without needing to know whether or not it is valid. However, when you want to convert to a SI timestamp (e.g. in order to add or subtract a number of SI seconds), then you do have to consider it; in this case it might be an error. Similar things apply with a positive leap second, although in that case the result is not an error. However, for positive leap seconds, when you are converting a UTC time in parts, into the UNIX timestamp, there is an additional time 23:59:60 for some dates. This can still be converted, although if you have a separate field for nanoseconds (or other divisions of a second) in the original UTC timestamp, then you will have to either subtract one second from the subsecond divisions, or change :60 to :59 and add one second. And, then again, you will also have to consider the leap second when dealing with SI seconds, whether they are positive or negative leap seconds. You will get the wrong answer if you fail to consider leap seconds either way (although in the case of negative leap seconds, there might not be a "right answer" in some cases). But, even if you do not consider these things, the timestamps will not be off by more than one second in either direction; this is not normally a problem, although in some cases it might be (which are the cases when it will be important to deal with leap seconds properly).
rswail 2y ago
Or we could adopt the "smearing" technique in either direction and we could do it hourly or daily or weekly or monthly or half-yearly or whatever interval as agreed. Maybe we should do it every 6 months no matter what. That way, everyone would know that on June 30 and December 31, there would be smeared seconds. That makes the "do it rarely and people will screw it up" problem go away.
amelius 2y ago
You need more than a negative leap second to get anytime close to Christmas, though.
ralferoo 2y ago
I don't even see the need for leap seconds at all (in either direction). Why should anyone care? All times are relative to some arbitrary fixed point in time anyway, so why are we so hung up on maintaining the status quo? Aside from the fact that just by ignoring the problem it'll probably go away - we've just had a period of adding a load of leap seconds to roughly compensating for the Earth rotating "too slowly" overall, which for a system that's inherently irregular and actually speeds up and slows down all the time, and just happens to have been "too slowly" ON AVERAGE. It now seems hat the rotation speed, on average, is "too fast" and now we need to undo some of that adjustment. If we'd just left it alone, it'd have been fine. And for all the hassle these leap seconds cause, what exactly has been the benefit? Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later. Just think, in 100 years, when your great grandchildren are enjoying their life, we might be a whole minute wrong. And if you went the other direction, back as far as all of recorded human history, and we might be out by an hour. Many of us are routinely forced to have our clocks out by an hour for "daylight savings time" every year anyway. For the very few cases where it might be useful to know the ACTUAL difference between the rotation and alignment of an abritrary fixed point on earth and an arbitrary fixed point on the sub, then THEY can use they own clock for that specialised purpose. And maintain a fixed adjustment to the atomic clock based time that everyone else uses, and they don't even have to round to a whole second for that - they can say NASA time is TAI+1.234s for instance and the only people who need know or care is NASA themselves.
- Mountain_Skies 2y ago
  For most civil purposes, it really doesn't matter but we're techies and it's in our nature to obsess over details like this, often to the determent of ourselves and the systems we're trying to maintain. It appears many of those with the most influence over setting the example for such things in the civil realm have indeed discovered the leap second is far more trouble than it is worth and now it is falling out of favor. For astronomical, aeronautical and other scientific purposes, they'll continue to deal with the hassles, but for the rest of us, it appears the era of leap seconds is slowly drawing to a close.
StevenWaterman 2y ago
"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth. Leap seconds are trying to ensure that, standing at the point we arbitrarily picked for UTC at noon, the sun will be at its peak. That doesn't feel like something that NEEDS sub-second precision. I mean - by walking from one side of a time zone to the other, you can have an hour or more of imprecision. https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg > Is there a single system currently in existence which can handle a leap minute? Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST. So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second. And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.
- throw0101b 2y ago
  > That doesn't feel like something that NEEDS sub-second precision. It does not need to be sub-second, but sub-seconds add up over time. The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump: * https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.
  - skrebbel 2y ago
    We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.
    - throw0101c 2y ago
mcculley 2y ago
Maybe there should be an analog of the Kardashev scale for civilizations capable of adjusting the rotation speed of their planet in order to make timekeeping easier.
gavinhoward 2y ago
Just make leap seconds first class. https://gavinhoward.com/2023/02/make-the-leap-second-first-class-an-open-letter-to-the-international-telecommunication-union/ https://gavinhoward.com/2023/02/make-the-leap-second-first-c...
gpvos 2y ago
The solution is obviously to have a leap second every half year, even when the difference with solar time is too small. Just alternative positive and negative leap seconds, and for additional fun, don't have a leap second when the difference with solar has shifted (in the right direction; it should be possible to keep the difference less than 1.5 second, probably much less). We could even do this every month, just to make sure there's enough testing opportunity.
RandomThoughts3 2y ago
I had to recreate an account just to reply to this discussion because I'm so appalled by its content. At the time of me writing this, 99% of the comment here are complaining about UTC moving to keep track of solar time or smugly arguing that we shouldn't do that. Different time standards exist. International Atomic Time (TAI) is a strictly monotic clock based on the average of multiple atomic clocks throughout the world. UTC is defined as a tweaking of TAI to approximate UT1, a rough definition of which would be the historic mean solar time at longitude 0. UTC shifts TAI to be within one second of UT1. That's both its definition and the whole point of it even exising. I repeat, it UTC didn't track solar time, it would have no reason whatsoever to even exist. If you want TAI, just use that. Stop complaining that UTC is not it.
afiori 2y ago
Almost nobody ever cares for UT1 except for astronomical observations (where you are also likely using a different calendar and using sidereal days) and we already have a perfectly working system for relating local times to each other and to UTC: timezones. The only things we should care about are local time (both as in clock time and in sun-position time) and universal timestamps to coordinate between local times and to use as canonical representations; leap seconds are useless or damaging to both of these. We already easily accept over 60 minutes of offset between clock time and sun-position time and I do not think that 3600 seconds can be ok but 3601 or 3599 cannot. It is also perfectly easy for a country to change its timezones or to adapt a non-whole-hour timezone (multiple countries have 15 or 30 minutes offsets) So my proposal is that the IERS never announces any leap anything ever again and in a few centuries some countries will shift their timezone by 15 or 30 minutes. This will be much more easily compatible with all current systems (we can right now create the timezone CETP and CETM for central European time plus 15 and minus 15) and in 400 years each at they leisure Europe/Berlin will be equivalent to CETM* (and CESTM if have failed to remove DST). No need to handle irregular minutes or hours, no fractional seconds offsets, no need to account for edge cases that are far too easy to ignore, just keep writing code that work with timezones (as you should already be doing) do not hardcode conversion between regional timezones (Europe/Berlin) and offsets (CET, CEST, CETM) as you should already be doing just updating your timezone tables (as you should already be doing as they change often). Just store one of: - UTC and timezone - dateless time with/without timezone - date with no time with/without timezone And you are ok, already prepared for the next few centuries of no leap seconds. * I don't know whether it would be CETM (that is +00:45) or CETP (+01:15).
1-more 2y ago
I gotta say I like this QNTM cat. Wrote Hatetris, "There Is No Antimemetics Division," and Absurdle. A fun explorer of adversarial computing environments. Pretty interesting
- pfraze 2y ago
  My team is kind of a miniature qntm fan club. We include copies of antimemetics as a new employee gift.
- starkrights 2y ago
  Holy shit, this is a world collision I wasn’t ever expecting to see. Thank you for pointing this out, “There Is No Antimemetics Division” is possibly my single favorite piece of fiction I’ve ever read, and I would’ve completely missed this connection otherwise.
gmiller123456 2y ago
Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is. Few people or systems even interact with a clock that is precise enough to detect the difference, and instead rely on clocks that are 100's or even 1000's of times less accurate than what would be required to even detect a leap second. And these clocks undergo thousands of corrections between leap seconds without a complaint. We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them. Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. But the leap second was chosen because it's large enough to be infrequent, and tiny enough that only a tiny fraction of systems will notice.
- AnotherGoodName 2y ago
  Yes if you use atomic time you won’t encounter these issues. Unixtime made a blunder of incorporating the leap seconds all those years ago so it’s not atomic hence the issue. Now you might think it’s crazy that Unix time incorporated non-atomic leap seconds when it doesn’t incorporate any other part of the local sun relative position in its counter and you’d be 100% right in that. Leap seconds absolutely belong in the local time printing functions and nowhere else. But the blunder was made and now computers by default don’t have atomic time and here we are.
- SonicScrub 2y ago
  Leap seconds are a problem because I have to deal with existing systems that use leap seconds and those that do not. Getting those systems in sync can be pain sometimes because of conversion from one format to another. Is it insurmountable? No. Is it annoying? Yes. Does it occasionally cause bugs that waste time and resources? Absolutely. I'd love to snap my fingers and make everyone use TAI, but unfortunately I'm stuck with UTC, GPS and TAI depending on sources.
  - gmiller123456 2y ago
thayne 2y ago
> You've reached a situation where campaigning for the whole world to change the way it measures time is simpler than fixing your code? It isn't just a code problem. Since leap seconds aren't predictable, you have to somehow distribute information about new leap seconds to everything, which is especially difficult for devices that aren't connected to the Internet. And as the article mentioned, there are multiple ways to deal with leap seconds, and there are tradeoffs involved in choosing which one, and depending on the circumstance different ways. And since different methods work best in different situations, that can result in inconsistencies between different systems.
xg15 2y ago
If the IERS ever announces a negative leap second, they should do it like this: https://m.youtube.com/watch?v=fr1li5NaltA https://m.youtube.com/watch?v=fr1li5NaltA

196 points by NKosmatos 2y ago

k310 2y ago

There is no mention of the affect this might have on investing or wagering. Or is the author keeping that close to the vest?

techdragon 2y ago
They don’t care about that. I mean it’s the opening paragraph… > I just want to see it. Just once. I want to watch that earthquake ripple through all of global electronic timekeeping. I want to see which organisations make it to January morning with nothing on fire.
- uoaei 2y ago
  Seems like a good dry run for redundancy/resiliency tests in the face of more catastrophic failures such as those that can result from solar storms.
danpalmer 2y ago
I agree with the author in finding some amusement in such trivial (in context) matters falling in the face of a phenomenon as fundamental as the planet's spin, something humans will likely never make a dent in.
- lovecg 2y ago
  Don’t give them any ideas! If I know humans, they’re the kind of species to figure out how to extract energy from the Earth’s rotation, overdo it way too much, and then deny that they’re the ones responsible.
  - maxbond 2y ago
    See also: > Tidal Energy Is Not Renewable > It is incorrect to consider tidal power as renewable energy. Harnessing tidal energy will pose more severe problems than using fossil fuels. ... Tides are induced by the rotation of the Earth with respect to the gravity of the Moon and Sun. The rotational energy of the Earth is naturally dissipated by tides slowly. Consuming tidal energy further reduces the rotational energy, accelerates the energy loss rate, and decelerates the rotation of the Earth. https://cs.stanford.edu/people/zjl/pdf/tide.pdf https://cs.stanford.edu/people/zjl/pdf/tide.pdf (I've not evaluated these claims in detail, I just thought you may be interested.)
    - mtoner23 2y ago
      It's completely wrong. He assumes energy will increase exponentially into the future to get to his wild claim that we could tidally lock to the moon in 1000 years. Even solar power out nuclear could not power humanity in that scenario
      - maxbond 2y ago
        Certainly if we grow exponentially for a further 1000 years we'll exceed the carrying capacity of this planet, however we derive our energy. I don't think that's a very interesting result. By "completely wrong" do you contend that using tidal energy doesn't decelerate the Earth's rotation?
        pas 2y ago
        Can we even change viscosity meaningfully? (Coastlines already form natural "dams". All we would do is move the coastline inward a bit, so as the tide flows through it it spins turbines. The water gets moved the same. The energy is already dissipated at the coasts, it would happen at the dams. Total dissipated energy is the same this way. Okay, if we start putting 4 km tall dams in the middle of the ocean we might somehow meaningfully change the viscosity.) The thesis in the PDF seems to be that somehow we can push the brakes more. Maybe. (So if we let the Sun/Moon grab some water then use the Earth to get it moving again, then it necessarily slows down the rotation. But there's already a lot of energy in moving and compressing water itself, sure it's "uncompressible" compared to gases, but there's plenty of molecular stuff to move around where energy can go. There's some tidal heating too.) It's verbose, but in a bad way, and it's structured in a way that makes it hard to comprehend. (And the whole pro-fossil-fuel framing is just .. huh.)
htthbjk 2y ago
[dead]

hirsin 2y ago

I feel like we'll get a (less physically _real_, but much more impactful) run of this "make it to the next day unscathed" adventure in 2038. Only 14 short years...

Dylan16807 2y ago

On leap minutes: > Because there's nothing computer programmers handle better than special cases which only occur every hundred years or so. How in the world could this be an improvement? If it's less than 60 times as disruptive, it's an improvement. > everybody's going to hate it at least sixty times as much as they hate leap seconds now I doubt that. > If something is difficult, you do it more often. It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain. > But before 1972 UTC and TAI were kept in much closer synchronisation [...] (No, I'm not advocating returning to this state of affairs.) Coward! But seriously, I think this hurts the previous argument significantly.

lmm 2y ago
> It has to be more often than leap seconds to really get those gears oiled. Unless this is a proposal to do leap deciseconds, I don't think this method reduces the pain. Yeah, if we're not going to abolish leap everything in UTC completely (which I think we should) then leaps need to happen at most quarterly. When the last leap second came through it was long enough since the one before that the bugs in Linux had been fixed and then unfixed.
- marcus_holmes 2y ago
  Do we introduce an unnecessary leap second and then negative leap second every year just to keep the gears oiled? And then if we need one for reals we can increase it to two leap seconds added and only one removed. Though of course that will cause bugs in any code that isn't expecting two leap seconds to be added and assumed that there would only ever be one. sigh
  - bee_rider 2y ago
    We could build it into daylight savings time. Instead of jumping an hour, we announce what the jump will be every year.
    - 2y ago

rblatz 2y ago

So my assumption was that Unix timestamps were monotonically increasing and that for the case of leap seconds the conversion from timestamp to UTC would take those into account and for some seconds have 2 mappings. That would keep the ordering of events, it would break assumptions like a day is 86400 seconds. But I guess they decided to keep that invariant, which makes negative leap seconds really hard. Maybe that’s a good trade off.

marcosdumay 2y ago
Unix keeps the 86400 seconds as an invariant, and ignores the IS size of a second. This should work just fine for negative leap seconds too, you just make your seconds shorter instead of longer. Of course, it's a near certainty that it won't work just fine. But it should.
kibwen 2y ago
The Rust standard library, which provides an API for monotonic timestamps, used to contain this silly hack (with appropriately exasperated comment) because in practice so many platforms and CPUs (Linux, Windows, BSD, x86, x64, Arm) failed to provide monotonicity despite their own documentation: https://github.com/rust-lang/rust/blob/80184183ba0a53aa4f491753de9502acd3d6920c/library/std/src/time.rs#L223-L250 https://github.com/rust-lang/rust/blob/80184183ba0a53aa4f491...
- zaptrem 2y ago
  // It seems that this just happens a lot in the wild. // We're seeing panics across various platforms where consecutive calls // to `Instant::now`, such as via the `elapsed` function, are panicking // as they're going backwards. Placed here is a last-ditch effort to try // to fix things up. We keep a global "latest now" instance which is // returned instead of what the OS says if the OS goes backwards. // // To hopefully mitigate the impact of this, a few platforms are // excluded as "these at least haven't gone backwards yet". Why exclude any platforms, just in case they start going backwards for whatever reason?
  - 2y ago

ooterness 2y ago

I have never understood why POSIX and NTP timescales work the way they do. They are positively bonkers when it comes to leap seconds. Time isn't even monotonic during the transition, because the epoch itself is redefined. Contrast this with the GPS or PTP timescales, which simply count seconds since a well-defined epoch. Formatting the date and time for humans to read is a sensibly separate process.

tverbeure 2y ago
But then GPS went off the rails and used a 10-bit number for count weeks, resulting in the 19-year week number roll-over (WNRO) problem. A few bits more would have solved a lot of problems.. Ref: https://en.wikipedia.org/wiki/GPS_week_number_rollover https://en.wikipedia.org/wiki/GPS_week_number_rollover
- cbhl 2y ago
  Given that the first GPS satellites were launched in 1978, saving a few bits was standard practice at the time -- bits were expensive. Code of the time also often had two-digit years (the infamous Y2K problem).
  - tverbeure 2y ago
    A full GPS navigation message is 37500 bits. I'll admit that it's not that simple: there are repeating fields in that message to avoid having to 12.5 minutes between each update. They could have kept the week number in the repeating message at 10 bits while having a non-repeating MSB?
    - akira2501 2y ago
      It's 1500. The full data set is 37500 but you get there by spreading the larger message across several subframes. The full data set includes ephemeris data for all other satellites. It's precisely as long as it needs to be. This also means there is a built in fixed maximum number of satellites in constellation. The time code gets 300 bits. It lasts 6 seconds and it's repeated every 30 seconds. Critically, it will always occur precisely on the top (:00 seconds) of the minute, or the bottom (:30 seconds) of the minute. Interestingly, most of the time code is used for /correction/ parameters, as precise values for these are required to accurately calculate time. Satellites themselves drift in performance as they age so these parameters are not static for the lifetime of the deployment. If you want to get into the nitty gritty, again, made in the 70s, so it's pretty approachable today: https://www.gps.gov/technical/ps/1995-SPS-signal-specification.pdf https://www.gps.gov/technical/ps/1995-SPS-signal-specificati...

samplatt 2y ago

qntm, I know you're reading this. As someone working on software that works on ships (aka, software that needs to change timezones and locations often and still maintain contiguous millisecond accuracy of all shipboard equipment events), this article has caused me significant psychological damage. There Is No AntiTimekeeping Division ...

pas 2y ago
> still maintain contiguous millisecond accuracy of all shipboard equipment events can you elaborate on the purpose of this? is it for legal requirements? some kind of "black box" recorder? why does timezone matter for such low-level event data?
- samplatt 2y ago
  Naval boats cost a fortune. The telemetry from the onboard engines/machines/computers needs to be in sync, and they don't always have compatible timekeeping systems, so sometimes it needs to be translated into a common format and recorded in our db's. If something goes wrong, a lot of parties both internal and external are interested in reviewing the (extremely detailed) logs for the purposes of insurance, or court-martial, or whatever.

theptip 2y ago

Riffing on “if it’s painful, do it more often”, I wonder if mandatory leap seconds every year, but trueing up the delta from N years ago, would be a good compromise? Regularity makes it easier to plan, and 6 months’ notice is not really enough for many OS distribution paths (eg IoT, embedded). Since the list of delta updates is queued, you could bake N years of updates into your system if it’s a fire-and-forget OS. A number in between 5 and 10 seems reasonable to me, but seeing as we are discussing living with 50 years of drift it could be higher. And sure, for this to work, allow non-integer deltas again; or just have a rule that you round the applied adjustment down. Seems no harder to bake in the last 50 years of leap seconds as to include to Olson TZ database in your distro.

lifthrasiir 2y ago
That's actually a good idea in the short term (i.e. less than one century). The length of the day (LOD) is thought to be linearly increasing in the long term though, so ΔT, the cumulative difference between past SI days and actual LOD, should be quadratically increasing and a delayed leap second adjustment would be too slow to catch up at some point in the future. Yet another possibility is to put any possible kind of leap second at the beginning of the year. The only requirement set by past CGPMs is that dUTC = UT1 - UTC should be in [-0.9, +0.9] seconds, so we can always put a positive leap second when dUTC is in [-0.9, -0.1]s and a negative leap second when dUTC is in [+0.1, +0.9]s, dramatically increasing the number of leap seconds without violating the dUTC requirement. If the dUTC requirement is a bit more relaxed (say, [-2, +2] seconds) then we can even mandate leap second every year! But well no, I'm strongly against the current form of leap seconds because it is already problematic in the short term and will be yet useless in the long term. Recall that ΔT is expected to be quadratically increasing in the long term; this means that the effectiveness of leap seconds is limited to the point when any small fixed number of leap seconds per year (12 in the current system, but anything larger than 1 will cause a problem) is no longer sufficient, and that point is not far from the point where the magnitude of ΔT is significantly large and leap seconds are absolutely required. As DST demonstrates, the world is probably fine with ~2,000 seconds of ΔT, which wouldn't happen before 2500, but at that point we would already start using double leap seconds per year at average. We would probably abolish leap seconds for that reason alone.

modeless 2y ago

I think it's weird how people react with such horror to the idea that maybe, just maybe, it wouldn't represent any kind of problem to the people of the 23rd century if 12:00 didn't correspond to the instant the sun was directly overhead, but instead a minute past. Nor would it cause any issue for people thousands of years from now if 12:00 was in the evening or the morning or any other part of the day or night. For those future people it would simply be the way things are, and it would stay that way their whole lives.

mjevans 2y ago
Noon already does not correspond to the sun overhead. Timezones, and IIRC the time of year and inclination relative to the equator matter too. However, irrespectively, it's basically never solar noon at noon if someone is using time zones rather than local solar time, which of course would be a custom timezone for that exact location.
- sfilmeyer 2y ago
  This article that I just came across does a nice job at explaining some of the nuances of solar noon https://www.timeanddate.com/astronomy/solar-noon.html https://www.timeanddate.com/astronomy/solar-noon.html . The time of year does matter a bit, but the effect is smaller than the effect of timezones. Their equation of time article includes a nice graph of the variations in time of solar noon at Greenwich. https://www.timeanddate.com/astronomy/equation-of-time.html https://www.timeanddate.com/astronomy/equation-of-time.html
  - Izkata 2y ago
    > This article that I just came across does a nice job at explaining some of the nuances of solar noon https://www.timeanddate.com/astronomy/solar-noon.html https://www.timeanddate.com/astronomy/solar-noon.html . And a related thing, the analemma - the sun's position at the same place on earth at solar noon over the course of a year doesn't resemble an arc, it's a figure-8: https://en.wikipedia.org/wiki/Analemma https://en.wikipedia.org/wiki/Analemma
2y ago

ikekkdcjkfke 2y ago

If I am asking for how many seconds since 1970, I'm literally asking for that, as if someone stood with a stopwatch (not a cellphone clock!) How you want to display that in various timezones i do not care

defrost 2y ago
Which specific stopwatch? Why don't you care about that stopwatch's drift over the past 50 years, the tempreture related variation, the errors induced by motion, air pressure and humidity? Would you prefer a count that's averaged over many from the same manufacturer, or from many over many manufacturers?
- 01HNNWZ0MV43FF 2y ago
  Switch to TAI + fixed offset I just don't give a damn whether solar time is a couple minutes off of calendar time. Seconds should be seconds. Solar time is a human construct, it shouldn't affect computers.
  - defrost 2y ago
    The person I responded to was interested in 50 years of seconds from a stopwatch. That's a mechanical device with multiple sources of error and a need to be wound regularly. The questions I asked are about common sources of drift in mechanical watches and wether or not they cared enough to attempt to account for them.
    - icehawk 2y ago
      You're conflating the term "stopwatch" with an all mechanical device. That wasn't even true at the time period specified-- the quartz movement had been created in the 1950s and the first quartz pocket watch had been introduced in the mid 1960s. The issues you bring up are only relevant to a particular set of devices that can be used as timepieces that measure the amount of time that elapses between its activation and deactivation-- and are are all stopwatches.

_ache_ 2y ago

I don't understand that someone just want chaos. I guess "Some people just want to watch the world burn". But negative leap second shouldn't be so noticeable since it will just be a jump from 31 dec 23:58 to 1 jan 00:00. Facebook made a lot of FUD about a negative leap second but I don't think it should be THAT a concern.

maxglute 2y ago

Always facinated by how complex standardizing timekeeping is. If here was a chance for a global redo, would there be a more simplified system?

htthbjk 2y ago
[dead]
akira2501 2y ago
Almost certainly not. The problem time keeping is meant to solve is coordination of physical movements between separated parties that have exceptionally limited and delayed communication capabilities. All of the time issues we deal with today are in service of keeping these important properties of our civil time in tact. In terms of computers we should happily ignore the problems of civil time, simply just use TAI, and use a provided database to convert this into "human display time" whenever necessary.
- School-Cotton 2y ago
  Leap seconds do absolutely nothing to fix the problems you’re talking about, for anyone. If we had never invented UTC and used TAI (+ time zone offsets) for civil time, the fact that civil time is drifting away from solar time on the order of a minute a century or so would at most be an obscure curiosity.
  - akira2501 2y ago
    The question was about historical time keeping in general, not about leap seconds specifically, so I'm not sure what point you're trying to make here. Also, astronomers care about leap seconds, and astronomy is an important tool in making observations which lead to predictions about our universe, so I wouldn't be so cavalier in labeling it an "obscure curiosity."
    - School-Cotton 2y ago
      I'm pretty sure astronomers don't care about leap seconds, and use more precise/fit-for-purpose tools.

etx 2y ago

[dead]

diego_sandoval 2y ago

Leap seconds are an extremely Earth-centric concept.

Ekaros 2y ago
Sometimes I have wondered is there proper write up of how messy intragalactic or intergalactic communications and time keeping would be. With or without FTL communication... Relativistic effects could actually be significant. Not to mention different rotation rates, day lengths, month lengths and so on... Leap seconds are comparatively simple problem...
- gpvos 2y ago
  They're considering creating a new time standard for the Moon. https://news.ycombinator.com/item?id=39916102 https://news.ycombinator.com/item?id=39916102
akira2501 2y ago
Yea, unfortunately, all of our really good telescopes are bolted to it.
- kibwen 2y ago
  JWST lives in the Earth-Sun L2 point, so I suppose that's still technically true.

knorker 2y ago

Negative leap seconds seem like they shouldn't be much of a problem. At least they don't involve repeating a second. No queries came in during a whole second? Who cares?

dark-star 2y ago
Yeah I'm wondering about that too. I don't think it could possibly be worse than having times like "23:59:60" pop up anywhere and messing every parser or regex up. It would just be like "huh, nothing bad (or good) happened during 23:59:58 and 0:00 according to our logfiles"
zokier 2y ago
Negative leap seconds will mean that there will be UNIX timestamp value that is invalid. What should systems do when they encounter such value? Generally UNIX time -> UTC conversion is considered to be infallible, negative leap changes that.
- knorker 2y ago
  Sure, in theory the string 20xx-12-31T23:59:59 should never be created. But if it is created, so what? A time span is off by a second, in the positive direction. Not good, but shrug. I'm not saying it's a good thing. At time recording it's like the computer froze for a second. Compare this to the problem of there being a unix timestamp integer that refers to two different times, which is what naive positive leap second implementations resulted in. Real time spans being impossibly negative. Positive leap seconds are orders of magnitude worse. Unless you're writing time keeping software, negative leap seconds can be ignored and will be "just fine". And if you are writing time keeping or benchmarking software, then this is just another thing to not have a misconception about. > Generally UNIX time -> UTC conversion is considered to be infallible And generally there's two seconds between N and N+2.
- zzo38computer 2y ago
  Normally, nothing. The invalid UNIX timestamp can still be converted to a (also invalid) UTC timestamp, without needing to know whether or not it is valid. However, when you want to convert to a SI timestamp (e.g. in order to add or subtract a number of SI seconds), then you do have to consider it; in this case it might be an error. Similar things apply with a positive leap second, although in that case the result is not an error. However, for positive leap seconds, when you are converting a UTC time in parts, into the UNIX timestamp, there is an additional time 23:59:60 for some dates. This can still be converted, although if you have a separate field for nanoseconds (or other divisions of a second) in the original UTC timestamp, then you will have to either subtract one second from the subsecond divisions, or change :60 to :59 and add one second. And, then again, you will also have to consider the leap second when dealing with SI seconds, whether they are positive or negative leap seconds. You will get the wrong answer if you fail to consider leap seconds either way (although in the case of negative leap seconds, there might not be a "right answer" in some cases). But, even if you do not consider these things, the timestamps will not be off by more than one second in either direction; this is not normally a problem, although in some cases it might be (which are the cases when it will be important to deal with leap seconds properly).

rswail 2y ago

Or we could adopt the "smearing" technique in either direction and we could do it hourly or daily or weekly or monthly or half-yearly or whatever interval as agreed. Maybe we should do it every 6 months no matter what. That way, everyone would know that on June 30 and December 31, there would be smeared seconds. That makes the "do it rarely and people will screw it up" problem go away.

amelius 2y ago

You need more than a negative leap second to get anytime close to Christmas, though.

ralferoo 2y ago

I don't even see the need for leap seconds at all (in either direction). Why should anyone care? All times are relative to some arbitrary fixed point in time anyway, so why are we so hung up on maintaining the status quo? Aside from the fact that just by ignoring the problem it'll probably go away - we've just had a period of adding a load of leap seconds to roughly compensating for the Earth rotating "too slowly" overall, which for a system that's inherently irregular and actually speeds up and slows down all the time, and just happens to have been "too slowly" ON AVERAGE. It now seems hat the rotation speed, on average, is "too fast" and now we need to undo some of that adjustment. If we'd just left it alone, it'd have been fine. And for all the hassle these leap seconds cause, what exactly has been the benefit? Since 1972, we've had 27 seconds added. 27 WHOLE SECONDS. That would have made absolutely no difference to anybody's life if the sunrise and sunset was 27 seconds later. Just think, in 100 years, when your great grandchildren are enjoying their life, we might be a whole minute wrong. And if you went the other direction, back as far as all of recorded human history, and we might be out by an hour. Many of us are routinely forced to have our clocks out by an hour for "daylight savings time" every year anyway. For the very few cases where it might be useful to know the ACTUAL difference between the rotation and alignment of an abritrary fixed point on earth and an arbitrary fixed point on the sub, then THEY can use they own clock for that specialised purpose. And maintain a fixed adjustment to the atomic clock based time that everyone else uses, and they don't even have to round to a whole second for that - they can say NASA time is TAI+1.234s for instance and the only people who need know or care is NASA themselves.

Mountain_Skies 2y ago
For most civil purposes, it really doesn't matter but we're techies and it's in our nature to obsess over details like this, often to the determent of ourselves and the systems we're trying to maintain. It appears many of those with the most influence over setting the example for such things in the civil realm have indeed discovered the leap second is far more trouble than it is worth and now it is falling out of favor. For astronomical, aeronautical and other scientific purposes, they'll continue to deal with the hassles, but for the rest of us, it appears the era of leap seconds is slowly drawing to a close.

StevenWaterman 2y ago

"Noon" is rooted in a physical phenomenon - when the sun is highest in the sky. But "UTC Noon" is arbitrary, because we had to pick a point on the earth. Leap seconds are trying to ensure that, standing at the point we arbitrarily picked for UTC at noon, the sun will be at its peak. That doesn't feel like something that NEEDS sub-second precision. I mean - by walking from one side of a time zone to the other, you can have an hour or more of imprecision. https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg https://i.ibb.co/r000S5s/caxxyddlsgp11.jpg > Is there a single system currently in existence which can handle a leap minute? Every system can handle a leap-hour, they happen twice a year in many countries, courtesy of DST. So let's just wait until there's 15 minutes of error - a couple of millenia from now. Then move the UTC prime meridian about 3.75 degrees / 400km, fixing the error while keeping UTC monotonically increasing 1 second per second. And to update our clocks, use the one mechanism that we already rely on comfortably - timezones. Add 15 minutes to each timezone, the same way we handle DST now.

throw0101b 2y ago
> That doesn't feel like something that NEEDS sub-second precision. It does not need to be sub-second, but sub-seconds add up over time. The Julian calendar wasn't that far off, but it was cumulative, so to fix things it took a ten day jump: * https://en.wikipedia.org/wiki/Gregorian_calendar https://en.wikipedia.org/wiki/Gregorian_calendar It is considered easier to have a few small(er) semi-regular jumps than suddenly having to making giant, sudden, one-off jump in the future.
- skrebbel 2y ago
  We make small semi-regular changes to timezones all the time. DST switches, governments arbitrarily deciding that their country is going yo be in a different timezone (at a 2 day notice), or move the DST switch day by 2 weeks, etc etc. This is a solved problem and it happens all the time. The systems and datastructures that can deal with this (eg tzdata and the process & people behind it) are already in place.
  - throw0101c 2y ago

mcculley 2y ago

Maybe there should be an analog of the Kardashev scale for civilizations capable of adjusting the rotation speed of their planet in order to make timekeeping easier.

gavinhoward 2y ago

Just make leap seconds first class. https://gavinhoward.com/2023/02/make-the-leap-second-first-class-an-open-letter-to-the-international-telecommunication-union/ https://gavinhoward.com/2023/02/make-the-leap-second-first-c...

gpvos 2y ago

The solution is obviously to have a leap second every half year, even when the difference with solar time is too small. Just alternative positive and negative leap seconds, and for additional fun, don't have a leap second when the difference with solar has shifted (in the right direction; it should be possible to keep the difference less than 1.5 second, probably much less). We could even do this every month, just to make sure there's enough testing opportunity.

RandomThoughts3 2y ago

I had to recreate an account just to reply to this discussion because I'm so appalled by its content. At the time of me writing this, 99% of the comment here are complaining about UTC moving to keep track of solar time or smugly arguing that we shouldn't do that. Different time standards exist. International Atomic Time (TAI) is a strictly monotic clock based on the average of multiple atomic clocks throughout the world. UTC is defined as a tweaking of TAI to approximate UT1, a rough definition of which would be the historic mean solar time at longitude 0. UTC shifts TAI to be within one second of UT1. That's both its definition and the whole point of it even exising. I repeat, it UTC didn't track solar time, it would have no reason whatsoever to even exist. If you want TAI, just use that. Stop complaining that UTC is not it.

afiori 2y ago

Almost nobody ever cares for UT1 except for astronomical observations (where you are also likely using a different calendar and using sidereal days) and we already have a perfectly working system for relating local times to each other and to UTC: timezones. The only things we should care about are local time (both as in clock time and in sun-position time) and universal timestamps to coordinate between local times and to use as canonical representations; leap seconds are useless or damaging to both of these. We already easily accept over 60 minutes of offset between clock time and sun-position time and I do not think that 3600 seconds can be ok but 3601 or 3599 cannot. It is also perfectly easy for a country to change its timezones or to adapt a non-whole-hour timezone (multiple countries have 15 or 30 minutes offsets) So my proposal is that the IERS never announces any leap anything ever again and in a few centuries some countries will shift their timezone by 15 or 30 minutes. This will be much more easily compatible with all current systems (we can right now create the timezone CETP and CETM for central European time plus 15 and minus 15) and in 400 years each at they leisure Europe/Berlin will be equivalent to CETM* (and CESTM if have failed to remove DST). No need to handle irregular minutes or hours, no fractional seconds offsets, no need to account for edge cases that are far too easy to ignore, just keep writing code that work with timezones (as you should already be doing) do not hardcode conversion between regional timezones (Europe/Berlin) and offsets (CET, CEST, CETM) as you should already be doing just updating your timezone tables (as you should already be doing as they change often). Just store one of: - UTC and timezone - dateless time with/without timezone - date with no time with/without timezone And you are ok, already prepared for the next few centuries of no leap seconds. * I don't know whether it would be CETM (that is +00:45) or CETP (+01:15).

1-more 2y ago

I gotta say I like this QNTM cat. Wrote Hatetris, "There Is No Antimemetics Division," and Absurdle. A fun explorer of adversarial computing environments. Pretty interesting

pfraze 2y ago
My team is kind of a miniature qntm fan club. We include copies of antimemetics as a new employee gift.
starkrights 2y ago
Holy shit, this is a world collision I wasn’t ever expecting to see. Thank you for pointing this out, “There Is No Antimemetics Division” is possibly my single favorite piece of fiction I’ve ever read, and I would’ve completely missed this connection otherwise.

gmiller123456 2y ago

Does anyone have an actual example where leap seconds are a problem? Specifically one that can't be solved simply by using Atomic Time? Maybe then we can figure out what the problem we're trying to solve is. Few people or systems even interact with a clock that is precise enough to detect the difference, and instead rely on clocks that are 100's or even 1000's of times less accurate than what would be required to even detect a leap second. And these clocks undergo thousands of corrections between leap seconds without a complaint. We add an entire day to the calendar about every 4 years. It's not a problem because everyone is aware of it. So I think the only real thing that needs to change about leap seconds is awareness of them. Leap seconds are needed in civil time because people's schedules are still dominated by the Sun. Not to the second, maybe not even to the hour. But the leap second was chosen because it's large enough to be infrequent, and tiny enough that only a tiny fraction of systems will notice.

AnotherGoodName 2y ago
Yes if you use atomic time you won’t encounter these issues. Unixtime made a blunder of incorporating the leap seconds all those years ago so it’s not atomic hence the issue. Now you might think it’s crazy that Unix time incorporated non-atomic leap seconds when it doesn’t incorporate any other part of the local sun relative position in its counter and you’d be 100% right in that. Leap seconds absolutely belong in the local time printing functions and nowhere else. But the blunder was made and now computers by default don’t have atomic time and here we are.
SonicScrub 2y ago
Leap seconds are a problem because I have to deal with existing systems that use leap seconds and those that do not. Getting those systems in sync can be pain sometimes because of conversion from one format to another. Is it insurmountable? No. Is it annoying? Yes. Does it occasionally cause bugs that waste time and resources? Absolutely. I'd love to snap my fingers and make everyone use TAI, but unfortunately I'm stuck with UTC, GPS and TAI depending on sources.
- gmiller123456 2y ago

thayne 2y ago

> You've reached a situation where campaigning for the whole world to change the way it measures time is simpler than fixing your code? It isn't just a code problem. Since leap seconds aren't predictable, you have to somehow distribute information about new leap seconds to everything, which is especially difficult for devices that aren't connected to the Internet. And as the article mentioned, there are multiple ways to deal with leap seconds, and there are tradeoffs involved in choosing which one, and depending on the circumstance different ways. And since different methods work best in different situations, that can result in inconsistencies between different systems.

xg15 2y ago

If the IERS ever announces a negative leap second, they should do it like this: https://m.youtube.com/watch?v=fr1li5NaltA https://m.youtube.com/watch?v=fr1li5NaltA