[HN Gopher] Hate leap seconds? Imagine a negative one
___________________________________________________________________
Hate leap seconds? Imagine a negative one
Author : rdpintqogeogsaa
Score : 80 points
Date : 2022-01-13 17:50 UTC (5 hours ago)
(HTM) web link (counting.substack.com)
(TXT) w3m dump (counting.substack.com)
| beeforpork wrote:
| A negative leap second would be a fun experiment. E.g. in
| Germany, the atomic radio clock signal DCF77 does have a bit to
| announce a positive leap second, but it has no way of announcing
| a negative leap second.
|
| https://en.wikipedia.org/wiki/DCF77
|
| Now, cheap DCF77 clocks (e.g., alarm clocks) don't care about the
| leap second bit anyway, but they will just adjust a few minutes
| later during normal resync. And they will do so just fine with a
| negative leap second. But some clocks, most probably those hidden
| in industrial systems, controllers, etc., may need to stay exact,
| and I am sure it's fun to find out which systems really care and
| will then fail and in what ways. :-)
|
| Interestingly, the Japanese and the British atomic radio clock
| signals can do negative leap seconds:
|
| https://en.wikipedia.org/wiki/JJY
| https://en.wikipedia.org/wiki/Time_from_NPL_(MSF)
|
| For WWVB, whether negative leap seconds are supported seems to
| depend on whether amplitude or phase shift modulation is used.
| fanf2 wrote:
| It is a curious fact that UTC is specified by the ITU in
| recommendation TF.460 https://www.itu.int/rec/R-REC-
| TF.460-6-200202-I/en which also includes a specification for
| how radio time broadcasts should be formatted. I don't know if
| any time signals actually use that format, tho.
|
| That part of the ITU used to be CCIR, the international
| consultative committee for radio, which goes a little way to
| explaining it, but it is still strange that it isn't the
| responsibility of the IAU, IERS, or SI.
| champtar wrote:
| Why are we adjusting when after 100 years clock would be less
| than 1 min off. We should deprecate UTC and just use TAI, ~40s
| difference right now.
| layer8 wrote:
| If we don't correct time-keeping to correspond to earth's
| rotation, their difference will increase roughly quadratically.
| Here is a table with estimates of when which delta (DUTC) will
| be reached:
| https://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable
| [deleted]
| black6 wrote:
| > It's important to know that there are exactly 86400 (24 _60_
| 60) UT1 seconds in a UT1 day. If the rotation of the Earth speeds
| up/slows down, the definition of a UT1 second changes since the
| number of seconds in a day is constant.
|
| I recently took an introductory Latin course and learned that
| ancient Roman time operated on the same principle. As the days
| got longer in the summer, so did the absolute length of time
| encompassed by an hour. Hard to make a sundial to automatically
| compensate, I imagine.
| bonzini wrote:
| I don't remember the details but it's actually just as easy.
| They're called unequal hours, Babylonian hours or Italic hours.
|
| More precisely the difference between two sunrises or two
| sunsets was 24 hours, so the hours were longer in winter and
| spring as days get longer, and shorter in summer and fall as
| days get shorter.
| fanf2 wrote:
| A sundial measures the angle between a point on the surface of
| the earth, the centre of rotation of the earth, and the sun.
| Because the earth rotates at a constant-ish speed, a sundial
| naturally shows equal hours. It is possible, but tricky, to
| make an unequal-hours sundial:
|
| https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/write-up.pdf
|
| https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article01.pd...
|
| https://www.cl.cam.ac.uk/~fhk1/Sundials/Newnham/article02.pd...
|
| https://www.cl.cam.ac.uk/~fhk1/Sundials/Selwyn/Selwyn.pdf
| adolph wrote:
| This is a fascinating read.
|
| _If the Earth speeds up enough, we might find ourselves
| pondering over the possibility of a negative leap second.
| According to the Time and Date folks [0], a day in 2021 is
| averaging about 0.2ms faster than the 84600 atomic seconds per
| day, ~70ms /year, so at most 14 years of this would put us over
| the threshold (super unlikely). In reality, we don't have to
| speed up a full 1000ms of rotation speed because there was always
| a fractional difference in UT1-UTC._
|
| https://www.timeanddate.com/time/earth-faster-rotation.html
| fanf2 wrote:
| Since that was published, the earth has been slowing down
| gradually. I keep a casual eye on IERS Bulletin A, which has the
| latest earth rotation observations, predictions for the next
| year, and a simple formula for longer-term estimates.
| https://www.iers.org/IERS/EN/Publications/Bulletins/bulletin...
|
| The line I look at is UT1-UTC = -0.1204 + 0.00020
| (MJD - 59593) - (UT2-UT1)
|
| which gives the current value of UT1-UTC (if -0.1204 grows to
| more than about +0.5 then we need a negative leap second) and the
| estimated long-term difference between earth's rotation and
| 24x60x60 seconds (0.20 ms fast was up to 0.26 ms fast a few
| months ago).
|
| Actually, I have some code that looks at Bulletin A for me,
| https://github.com/fanf2/bulletin-a which until recently was
| estimating that the next leap second would be a negative leap
| second in about 2028/9. But now its guess is receding into the
| future past 2030.
|
| I have a few tweet threads on this topic, which you can find via
| https://twitter.com/fanf/status/1478767806187552776 with some
| clicky-clicky to dig the older ones out of twitter's delightful
| user interface.
|
| See also https://news.ycombinator.com/item?id=25145870 for some
| previous discussion here on this topic.
|
| So nothing dramatic is likely to happen any time soon, though the
| current situation is quite weird.
| d0mine wrote:
| There is Python script https://github.com/zed/leap-second-
| client/
| gamache wrote:
| Applying a negative second to a fleet is a solved problem, using
| the "leap smear" technique by Google.
| https://developers.google.com/time/smear
|
| Applying it to millions of individual servers with different
| OSes? I'll make the popcorn.
| throw0101a wrote:
| > _Applying it to millions of individual servers with different
| OSes? I 'll make the popcorn._
|
| The FreeBSD folks test for this:
|
| * https://lists.freebsd.org/pipermail/freebsd-
| stable/2020-Nove...
|
| The kernel and ntpd are fine with it. Applications:
| -\\_(tsu)_/-
| ncmncm wrote:
| Leap smear _is itself_ an overwhelmingly bigger problem than a
| leap second.
|
| A leap second is over in a second. With leap smear you are out
| of sync with the rest of the world for many hours. And, there
| are at least three different leap smear schemes I know of: a
| massive judgment failure that happens again and again.
|
| The sensible alternative would be to eliminate leap seconds
| entirely for a few decades, and maybe stage a leap minute,
| eventually, or a leap hour in some far-off century, or never.
| It doesn't matter if the sun is ever exactly overhead at noon,
| because it isn't anyway, almost everywhere.
| fennecfoxen wrote:
| > a leap hour in some far-off century
|
| Just change your time zone offsets at that point, honestly.
| vinkelhake wrote:
| > A leap second is over in a second.
|
| The problem isn't one where you hold your breath and squeeze
| your eyes shut for a second while the unpleasantness passes.
| The problem is when you have tons of code running and you
| don't know exactly how it'll deal with this very rare event.
|
| If you're faced with an upcoming leap second there are
| various ways of dealing with it. One way is to do an audit of
| the code and hope that you can verify the most important
| parts. Another way is to smear and hope that most programs
| won't be negatively affected by reported seconds being
| 0.00001s off.
|
| There are other options, but I don't think there's an
| "obviously correct way".
| toast0 wrote:
| > And, there are at least three different leap smear schemes
| I know of: a massive judgment failure that happens again and
| again.
|
| There's also the exciting version where some of your time
| servers do it one way, and some do another; you could
| probably pick two traditional servers, and then one of each
| of the others and have a really terrible day. From experience
| with a setup where 4 servers were traditional and one was
| smeared, there was a lot of variation in time; but thankfully
| my systems weren't relying on time measured on different
| servers to be very consistent.
|
| IMHO, leap smear probably should have been done with standard
| time on the wire, and the host agent doing the smear. But
| that would be more effort than doing it on the time servers,
| so there you go.
| StefanKarpinski wrote:
| If I've learned one thing about dealing with exceptional
| events, it's that the less often they happen, the less likely
| you are to handle them well. Switching from leap seconds
| every few years to leap minutes every century, pretty much
| guarantees we'll screw it up. But maybe that's ok? Y2K was a
| fat nothingburger, after all the fuss.
| bee_rider wrote:
| Push it out to a century, and then hope we have the ability
| to slightly accelerate the planet by then?
| jonas21 wrote:
| Y2K was a fat nothingburger, _because of_ all the fuss.
| Millions of person-years and $300 billion were spent to
| avert disaster - and it worked!
|
| But then all anyone ever sees is that nothing went wrong,
| and they assume it was nothing to begin with.
| wmf wrote:
| That's why we should eliminate leap seconds/minutes/hours
| and just change time zone definitions to keep the sun
| overhead near noon.
| StefanKarpinski wrote:
| Is the concept that UTC would become "detached" from a
| particular location on Earth and the offset of time zones
| relative to UTC would change over time (very infrequently
| since it would take on the order of a millenium for a
| time zone to shift by half an hour).
| wmf wrote:
| Exactly.
| an1sotropy wrote:
| It's a little like a public health success: if done right,
| the worst that happens is that people have to prepare, and
| people complain about it, but disasters are avoided.
|
| Pre-Y2K there was a lot of fuss and hand-wringing, but
| there was also a lot of software development that happened
| to ensure that Y2K would not be a disaster. So then when
| Y2K rolled around the preparations mostly worked.
|
| My first programming job in high school was over-hauling a
| (mainframe-hosted) code base for handling lab data at a
| hospital. This was in the mid-90's; before most of the Y2K
| fuss had started. Without my work, pee and poo samples
| would be time traveling from the late Victorian era. You're
| welcome.
| zamadatix wrote:
| It's not particularly interesting to be out of sync with the
| rest of the world, you always are and messages to/from
| external entities are even more so constantly. When it is
| interesting is when the thing you are doing is a function of
| time e.g. GPS or locked-step systems spanning geographic
| regions or so on. In almost all of those cases you're
| probably well used to dealing with time problems that are a
| bigger pain than a leap second. For those that aren't hiding
| the leap second and being off by slightly more than usual for
| a bit is probably better than hoping everyone can be prepared
| to suddenly care a lot about handling time oddities for one
| second every year (or century as you propose).
| civilized wrote:
| Now we're going to have "lies programmers believe about time":
|
| 1. Seconds in one time system last the same amount of time as
| seconds in another time system
|
| 2. Seconds in the same time system last the same amount of time
| as each other
|
| 3. Time numbers are strictly increasing - the same time number
| can't happen again
|
| 4. [etc, kill me]
| karmakurtisaani wrote:
| Just wait until we reach the proper space age and start
| traveling at speeds close to the speed of light. Taking into
| account the relativistic effects is going make more than a few
| coders switch carees to organic farming.
| gorjusborg wrote:
| I'd like to think my descendants will be beet farmers in a
| far away solar system.
| Swenrekcah wrote:
| Probably takes some serious skills to be an organic farmer on
| Ceres.
| bee_rider wrote:
| Conveniently it turns out that the results are the same
| independent of your skill.
| nradov wrote:
| GPS satellite designers already have to account for clock
| skew due to relativistic effects. A nice little real world
| confirmation of the theory.
| ISL wrote:
| Those corrections (both special and general relativistic,
| with opposite signs) are already required to allow GPS to
| function.
| monocasa wrote:
| Luckily clock skew already happens and is handled more or
| less by the current systems. The difference between the
| system moving at relativistic speeds versus a crystal being
| slightly out of spec add up to the same result. Incorrect
| number of ticks for a given proper time interval.
|
| That's part of the genius of Leslie Lamport, embracing the
| fact that your distributed clocks aren't consistent, so start
| looking at effects through distributed systems from a light
| cone perspective just like you do with relativity.
| willis936 wrote:
| Clock skew is in error. Relativistic time dilation is not.
| Both clocks will be right and disagree. You can't escape
| answering the question: do I care about the time elapsed at
| home or the time elapsed here?
| monocasa wrote:
| At the end of the day there's always skew; crystals in
| systems aren't made to perfect tolerances. In fact I'm
| not even sure how you would define perfect tolerances for
| clocks in a meaningful way.
|
| So at the end of the day it doesn't matter if it's in
| 'error' or a fundamental to the physics even under
| perfect conditions. Neither are really under your control
| and both have the same answer.
| dasil003 wrote:
| If you need time elapsed then you implicitly need a frame
| of reference in the same way that a clock time needs a
| time zone to be meaningful in a global basis. In practice
| if you wanted this it would mean having a timer colocated
| within your frame of reference as there is no scalar
| representation of a frame of reference that would allow
| you to do timestamp calculations. Timestamp math only
| works as a hack because we mostly stay relativistically
| close to Greenwich.
| fanf2 wrote:
| Astronomers use mathematical models of the solar system
| to translate between barycentric time, geocentric time,
| and terrestrial time, which are all different
| relativistic frames of reference. Only TT has actual
| clocks: TAI ticks at the same rate as TT, tho for
| historical reasons there is a fixed offset. That isn't
| counting the clocks derided from observing the orbits of
| the moons and planets...
| kuschku wrote:
| We already define time relative to 1970-01-01, relative
| to the mean solar noon in Greenwich.
|
| We should also define the length of a second to mean "at
| sea level in Greenwich".
| kempbellt wrote:
| Sea level when the tide is in, or out?
| fanf2 wrote:
| "sea level" is short for "mean sea level"
| tialaramex wrote:
| This just means the "length of a second" wanders around
| randomly and is thus useless. So now "a second" isn't any
| particular amount of time, and you've lost all ability to
| really measure time except in a vague inexact sense.
|
| The quest to eliminate irreproducibility from metrication
| is why SI did all that work to finally eliminate the
| kilogram prototype. The second was defined reproducibly
| decades ago _because_ trying to define it based on our
| planet 's inconstant spin was such a failure.
|
| The fact that the Earth's spin is not constant is perhaps
| frustrating, but like other facts just insisting it isn't
| true doesn't help you.
| fanf2 wrote:
| Right, but general relativity matters for how astronomers
| define their timescales, and how they are measured and
| maintained in practice: there are different scales for
| barycentric time (at the centre of gravity of the solar
| system), geocentric time (centre of the earth) and
| terrestrial time (on the surface of the rotating geoid).
| TAI is supposed to tick at the same rate as TT, so it
| depends on a model of an equal-gravitation version of sea
| level (the geoid) and the relative height of the time
| labs. In particular, NIST is a mile high in Colorado so
| their clocks tick a lot faster than (say) NPL by the
| Thames in west London.
| eftychis wrote:
| We do: all these are taken into account for satellites. In
| particular GPS is one of the prime examples as it is affected
| by both special and general relativity and how fast time
| elapses is critical to its function.
| npongratz wrote:
| We already do:
| https://infiniteundo.com/post/25326999628/falsehoods-program...
|
| HN discussion (among others less recent and/or less popular):
| https://news.ycombinator.com/item?id=19922062
|
| More falsehoods:
| https://infiniteundo.com/post/25509354022/more-falsehoods-pr...
| 2muchcoffeeman wrote:
| Why wouldn't we decouple time from the earths orbit?
|
| Instead have 2 calendars: the normal date time is standardised,
| no leap anything and simply increases. The orbital time tracks
| the earths revolution around the sun.
|
| Sure, eventually the two will drift. But leap days account for
| 3 weeks-ish of time for the average person through out their
| life (let's assume 80 years life span for arguments sake). So
| this doesn't seem so hard to adjust to.
| [deleted]
| vbezhenar wrote:
| I don't understand why do we need to have leap seconds. Even if
| time on Earth moves few minutes back, nobody would notice but
| astronomers. If time moves one hour back, just change your local
| zone offset, it happens all the time anyway, and that's about it.
|
| It makes time calculations unreasonably complex without any
| benefit.
| umvi wrote:
| > I don't understand why do we need to have leap seconds. Even
| if time on Earth moves few minutes back, nobody would notice
| but astronomers.
|
| Right, and nobody's stopping you from using a sundial instead
| of a GPS watch if you don't care about high precision
| timekeeping. And if you do care about high precision
| timekeeping but hate leap seconds, you can use International
| Atomic Time (TAI). It all comes down to standardization. You
| might enjoy reading this:
|
| https://www.nist.gov/pml/time-and-frequency-division/nist-ti...
|
| Basically, standardization is hard. Not just for time, but any
| measurement (weight, length, etc). How do you absolutely
| guarantee that an airplane part made in France and the same
| airplane part made in Brazil are _exactly_ the same dimensions
| /weight? You need standards. And those standards have slightly
| changed over time in an effort to achieve higher
| consistency/future-proofing.
|
| Time is especially difficult because gravity and speed affect
| time thanks to relativity. So how can you come up with a
| universally agreed upon definition of "one second"? The current
| best solution we have is to take a weighted average of 300+
| atomic clocks. That's how we define TAI, and by extension, the
| second. However, people expect noon to be "the time when the
| sun is at its highest point in the sky". Leap seconds are used
| to make non-TAI time systems align exactly with the rotation of
| the earth. Without leap seconds, your local day will slowly
| drift until (millennia later) "noon" is happening in the middle
| of the night. And without leap years (which align the planet's
| orbit around the sun) your seasons will slowly drift for the
| same reason.
| tialaramex wrote:
| > people expect noon to be "the time when the sun is at its
| highest point in the sky"
|
| A) No they don't, which makes sense because
|
| B) No it isn't
|
| And "millennia later" is really overstating how soon this
| would happen. If you did this, every few millennia if people
| are very angry about it they would merely need to change
| their time zone definition one step. Now, how many millennia
| does it take to change time zone definitions where you live?
| Oh that's right they _weren 't even invented a thousand years
| ago_.
|
| So, firstly, people do not actually expect the sun to be "at
| the highest point in the sky" at 1200 local time, it hasn't
| been in their lived experience so why would they? They'd be
| surprised if it happened at 0800 or 1600, but precisely 1200
| doesn't matter to them. Which is good because it isn't, it
| hardly could be.
|
| Nobody was proposing to eliminate leap years (although
| perhaps renaming them "leap days" and marking them as a
| holiday might be better) which are a whole _different_
| problem.
| [deleted]
| fanf2 wrote:
| And leap seconds will stop working (as currently specified)
| in one or two thousand years when the earth is slow enough
| that we need ~12 each year. Time zone adjustments will
| continue to work much longer.
| https://www.ucolick.org/~sla/leapsecs/dutc.html
|
| There is a confounding issue, though: the continual messing
| around with daylight saving means that time zones have to
| be relatively easy to alter. But if (as seems likely)
| daylight saving is abolished, this flexibility will ossify,
| so it might not be so easy to use in the distant future...
| FabHK wrote:
| Pick any two:
|
| 1. 86400 seconds a day
|
| 2. SI seconds
|
| 3. Noon synced up with the sun
|
| With UTC, we drop 1.
|
| With UT1, we drop 2.
|
| With TAI, we drop 3.
|
| Maybe we should have gone with TAI, or with UT1 - I think
| that's what Julia does, sort of:
|
| https://docs.julialang.org/en/v1/stdlib/Dates/#footnote-1
| bumbledraven wrote:
| Using TAI was also djb's solution to the problem.
| https://cr.yp.to/proto/utctai.html
| mavhc wrote:
| Yep, just use TAI, you're already converting time to show it
| locally, so no problem also including leap seconds in that
| conversion
| layer8 wrote:
| If we don't apply corrections to UTC to match earth's rotation,
| their difference will increase roughly quadratically. Here is a
| table with estimates of when which delta (DUTC) will be
| reached:
| https://www.ucolick.org/~sla/leapsecs/dutc.html#dutctable
___________________________________________________________________
(page generated 2022-01-13 23:00 UTC)