[HN Gopher] An Update on Leap Seconds (2022)
___________________________________________________________________
An Update on Leap Seconds (2022)
Author : fanf2
Score : 73 points
Date : 2023-01-30 10:42 UTC (12 hours ago)
(HTM) web link (dotat.at)
(TXT) w3m dump (dotat.at)
| [deleted]
| pbohun wrote:
| Time is one of the most difficult things to deal with in
| computing. There are applications that work best with a
| monotonically increasing time. Having a 'second' that stretches
| constantly back and forth would make time calculations
| essentially impossible, hence the leap second, a discrete
| adjustment.
|
| Ideally, one would have a monotonically increasing time from some
| event, but then transforming that into some human readable time
| is complicated. And of course, what actually is the human
| readable time? When should 'noon' actually be and should it be
| adjusted continuously with leap seconds, minutes, etc.?
| Xeoncross wrote:
| Considering time only moves forward, I would say computers
| aren't the only thing that would have issues with a second that
| moved backwards.
|
| Time seems to simply be a way to keep track of matter in space,
| that is it seems to be a construct to explain the state of
| matter. Unless matter's state is being undone in space, I can't
| imagine how time would move backwards.
| neodon wrote:
| What?
| lalaithion wrote:
| We have a monotonically increasing time, TAI (International
| Atomic Time). The problem is that people want 00:00 each day to
| correspond with midnight, and so we need either (a) varying
| seconds or (b) leap seconds. So we have UTC (Coordinated
| Universal Time) which uses leap seconds to stay within one
| second of UT1, which is the mean solar time at 0 degrees of
| longitude, and which has variable seconds.
| zarzavat wrote:
| Didn't we give up on having "the time" correspond to solar
| time in the 1800s with the advent of railways? Unless you
| live exactly upon a specific set of lines on Earth, 00:00
| _never_ corresponds to midnight, leap seconds or not.
| lalaithion wrote:
| Fair. It would be more accurate to say that people want the
| time of midnight and noon to be consistent across ~decades
| and centuries (and if the leap second isn't going to happen
| the leap minute or hour almost certainly won't...).
| benlivengood wrote:
| Human-readable time can be as simple as tagging monotonically
| increasing timestamps for the start of every day at the prime
| meridian. Calendars can count days and weeks and months as
| normal, but the exact timestamps won't exist for future dates
| until we observe them, which is fine. It's not a huge dataset
| to publish timestamps for the majority of historical times, or
| storing interpolations between months or entire years.
|
| Approximations in calendar time can be used for the future
| where precision timekeeping is not needed (the holiday party
| next year at 8:00PM), and exact monotonic timestamps can be
| used where precision is needed (e.g. the timestamp to start a
| re-entry or orbital insertion burn around Mars).
|
| Our calendars are already merely tags/counters for physical
| events (solstices, new moons, high noon) we observe, so making
| that distinction official in timekeeping standards makes sense
| to me.
| layer8 wrote:
| I try to write software such that it would work for a time
| traveler (who takes the computer running the software with
| them) as much as possible. That is, distinguish between elapsed
| time within the system, which is monotonically increasing, vs.
| calendar time and time of day, which might go back and forth
| arbitrarily and is just a label. This isn't always possible,
| for example with regard to external last-modified times, but
| designing with that distinction in mind tends to make systems
| more robust.
| jonathankoren wrote:
| Fun fact about leap seconds. You can _never_ get rid of them.
|
| Let's say you do something reasonable, like put an atomic clock
| on the moon, or anywhere really, but let's stick with the moon.
|
| You build your clock, you sync it with the Naval Observatory.,
| and launch it to the moon.
|
| 48 years later, who shows up? That's right, the leap second.
|
| Your lunar clock is losing 56 microseconds a day due to an
| insufficiently curvy spacetime (e.g. _gravity_ ).
|
| https://www.nature.com/articles/d41586-023-00185-z
| Dylan16807 wrote:
| Relativity is not a leap second issue, it's a calibration
| issue. You can't just move an atomic clock and keep counting.
| Even between slightly different elevations on earth, you get
| different raw numbers.
|
| So unless you differ from Earth's calibration on purpose, you
| won't lose 56 microseconds a day. You'll stay in sync.
| zokier wrote:
| > At the same time, celestial navigation was still important, so
| civil time needed to stay close to UT.
|
| There is lot to unpack in this statement.
|
| 1) In around 1970 the importance of celestial navigation is
| questionable. Systems like LORAN and Decca were well established,
| and OMEGA became operational in 1971.
|
| 2) The importance of second-level accurate celestial navigation
| is even more dubious, considering that celestial navigation is
| not super precise to begin with.
|
| 3) Most crucially the link between the needs of navies and civil
| time is weak; even if we assume that navy needed accurate
| approximation of UT, it doesn't explain why civil time needed to
| follow.
|
| Note that afaik celestial navigation relies on nautical almanacs
| that are published yearly. It would have been trivial to include
| DUT1 correction values in there too if needed.
| bmelton wrote:
| Having actually sailed, I can attest to a couple of things:
| Commercial-grade sailboats are filled with gremlins, and the
| ocean is enormous.
|
| I can count on zero hands the number of times I've been on a
| sailboat where everything worked perfectly. This is a function
| of cost moreso than criticality, but the amount of time and
| energy required to upkeep a sailing appliance that consistently
| endures some of the worst things nature can throw at it would
| practically require replacing every part with every sail.
|
| Sailboats shake, vibrate, and shudder as they are subjected to
| wind and waves. Topside parts enjoy the added joy of being
| continuously subjected to sun, salt, and wind.
|
| In short, things break. Slightly longer, it is fair to expect
| that on any given day, something will be broken. Whether a car
| that holds a mainsail to its mast, or a fuse that powers your
| navigation equipment, or what have you, those systems are great
| and wonderful so long as they are operational, but if you are
| halfway across the Atlantic ocean, hundreds of miles away from
| the nearest land mass in the dark, there is no Radio Shack to
| visit, and no way to find it without having to fall back to a
| compass and some celestial orientation.
|
| No matter how good they are advertised as being, absolutely
| zero systems should be considered trustworthy in a big sea.
| dylan604 wrote:
| I was right there with you until you mentioned Radio Shack. I
| had to look at the date to see if I woke up in the 1980s, as
| that's really the last time Radio Shack would have been
| useful (unless you want to buy a shitty mobile phone). Since
| you used proper name upper casing, that's what I assumed.
| Especially since you're talking consumer sailing boat where
| the actual radio shack of a boat is less a shack and usually
| just a radio unit bolted into some dead space so it won't
| take up usable space from something else.
| bmelton wrote:
| Radio Shack was a placeholder for the more complicated and
| technical explanation. In reality, replacing boat parts is
| done by manufacturers and marine shops that are usually
| located in or near marinas, much of the time requiring
| someone to order the parts special except for popular
| makers of products.
|
| There _is_ no Radio Shack for marine electronics, but it 'd
| be great if there were.
| dylan604 wrote:
| There _is no_ Radio Shack for anything useful is the gist
| I was going with. An old fart recognizing another old
| fart. It 's kind of a shibboleth at this point.
| Ekaros wrote:
| If you are doing celestial navigation and need second-level
| accuracy you can correct for it by adding the extra seconds.
|
| And my understanding is that if celestial navigation isn't good
| enough you are probably close enough to land to just navigate
| based on sight and map.
| throw0101c wrote:
| I guess there's a bit of a 'philosophical' question here: is a
| _day_ 86400 seconds, or is it one rotation of the Earth on its
| axis?
| deathanatos wrote:
| > _or is it one rotation of the Earth on its axis?_
|
| Or the amount of rotation required to point towards the sun
| again, which is slightly more than one rotation (remember, we
| orbiting while spinning, so noon to noon is a bit more than
| 360deg). This is a solar day; your definition is called a
| "sidereal day" (and is a real thing, too).
|
| (And the solar definition has issues, too, which leads to,
| e.g., mean solar time...)
|
| https://en.wikipedia.org/wiki/Sidereal_time
| simcop2387 wrote:
| 1 rotation as measured againsg what? The sun, the stars, the
| cmb? All of those are ever so slightly different too.
| jayknight wrote:
| 1 solar day is how long it takes between "high noon"
| (meridian transit) on two consecutive days.
|
| 1 sidereal day is about 4 minutes shorter and the time it
| takes for the stars to be in the same position.
|
| As far as I know, unless you're doing certain types of
| astronomy, you're using solar days.
| bluenose69 wrote:
| You also need sidereal days for computing the Coriolis
| parameter, and both oceanographers and meteorologists need
| to know that. So the astronomers are in good company (or
| bad, depending on your point of view).
| AdamN wrote:
| Both. That's why there's UT1 and UTC for different purposes.
| maxnoe wrote:
| * That's why there's UT1 and TAI for different purposes.
|
| UTC is a (strange) compromise between both: ticking SI
| seconds like TAI but being kept within 1 second of UT1.
| bloak wrote:
| As I see it, UTC is an excellent compromise for the purpose
| of civil timekeeping. But it would be easier in future if
| computers would use TAI internally and convert to UTC for
| display.
| layer8 wrote:
| As the article points out, what is being broadcast to
| keep systems synchronized is UTC, and TAI only exists on
| paper, or as derived from UTC. (Note that even if you
| have an atomic clock, that isn't TAI. TAI is some average
| of atomic clocks distributed over the earth, due to
| gravitational and hence relativistic differences.) UTC is
| effectively our master clock, and changing that would
| require a large number of technical and legal changes. So
| it's much easier to just increase the DUT1 tolerance and
| stop having new leap seconds.
| Nullabillity wrote:
| UTC solves _nothing_ for civil timekeeping, compared to
| TAI.
|
| Timezone bands are massive. If they were perfectly
| straight (they aren't) then civil time in any one place
| would be off by up to 30 minutes in either direction,
| depending on the location. In reality they line up with
| political entities instead, creating even larger
| discrepancies (with the extreme case being China, where
| some regions are _hours_ off).
|
| Compared to that, a second every couple of years is
| completely irrelevant.
| Ekaros wrote:
| Not to forget the political push to adopt offsets that
| don't even match correctly. Instead you know fixing the
| timetables and rules in single go, if that effect is
| wanted.
| shadowofneptune wrote:
| For civil purposes, I feel the second still makes more sense as
| 1/86400 of a solar day. Unless you have an atomic clock, you
| cannot accurately keep to the SI unit over weeks or months
| anyway, let alone the time between leap seconds.
| zokier wrote:
| Practically everyone has access to atomic clocks these days
| by the virtue of having dozens of them whizzing over our
| heads broadcasting their time and having handy-dandy
| receivers in our pockets. And even running your own atomic
| clock these days is not that far fetched, see open timecards
| for example.
| eCa wrote:
| And then you have sports, some of which are (or have been
| determined) on the level of 1/1000 of a second. I'm not sure
| how that level of precision goes hand in hand with that
| definition of seconds.
| hacker_junky wrote:
| the chicken definitely came first!
| BlueTemplar wrote:
| The first one under the Julian year paradigm, one rotation
| compared to the Sun under the Julian day paradigm. (Neither of
| which to be confused with the Julian calendar.)
|
| What I do not understand, considering the above (Julian years
| and days have been used for a long time in respectively
| paleontology and astronomy, haven't they ?) as well as from TFA
| :
|
| > Abolishing leap seconds will be helpful for users that have
| very tight accuracy requirements. UTC is the only timescale
| that is provided by national laboratories in metrologically
| traceable manner, i.e. in a way that provides real-time access,
| and allows users to demonstrate exactly how accurate their
| timekeeping is.
|
| > TAI is not directly traceable in the same way: it is only a
| "paper" clock, published monthly in arrears in Circular T as a
| table of corrections to the various national timescales. (See
| the explanatory supplement for more details).
|
| So, what are we waiting for to just have _both_ scientific time
| and civil time being broadcast _separately_ (and scientific
| time with _more_ precision and frequency, not less !), and then
| you use one or the other as appropriate ?
| layer8 wrote:
| > So, what are we waiting for to just have _both_ scientific
| time and civil time being broadcast _separately_
|
| That would require either doubling the radio frequencies (and
| other channels) used for time broadcast, or changing the
| transmission format to include both (so not really separate).
| Some systems actually broadcast the current leap second count
| along with UTC, so TAI can easily be derived. Of course, that
| presumes that UTC and TAI keep being related by a leap second
| count. Going to fractional seconds of delta would again
| require changing protocols and data formats.
|
| In addition, we'd presumably still like a civil-time second
| to be the same as an SI second, and not go back to the
| "rubber seconds" of the 1960s. But how then would we handle
| the fact that the solar day isn't exactly 86400 SI seconds
| [0]? Add/remove some fractional seconds at the end of each
| civil day? That might cause even more issues in software than
| leap seconds.
|
| [0] https://www.timeanddate.com/time/earth-rotation.html
| BlueTemplar wrote:
| Right, you still might need computers having to deal with
| the fact those two don't align, which would be messy in a
| way that is acceptable for (pre)historical dating, but not
| for realtime systems.
|
| Right, leap seconds it is then, but note that that and
| minutes/hours/days/years here is something that is only
| required for human interfaces, while the computer itself
| only cares about a monotonically increasing seconds counter
| on its internal clock, which is required to be
| stopped/started/re-adjusted once in a while anyway.
|
| Oh, and conversion between scientific and civil time is
| then the job of local polities, which they do for timezones
| anyway.
| layer8 wrote:
| Software also cares about which second is which when
| comparing times originating from different systems, or
| from earlier/later instances of the same system. A
| monotonically increasing local clock isn't sufficient if
| you can't tell the relation between time _x_ from your
| clock and a time _y_ from another clock. So you need some
| way to establish that relation. Similar for mapping to
| civil time. You need to know what actual time the source
| time is.
| BlueTemplar wrote:
| That relation is established by knowing which standard
| each clock uses, so I am not really sure what the problem
| is ?
| layer8 wrote:
| Well, which standard do you use, and how do you ensure
| that your internal clock remains synchronized to that
| standard? For example, when starting your system, how do
| you determine the correct initial value for your clock,
| and how do you compensate for clock drift? Just having
| _some_ monotonically increasing counter starting at some
| arbitrary value isn't enough.
|
| The current answer is everyone uses UTC, and they keep
| synchronized by observing the one universally
| disseminated time, which is UTC.
| [deleted]
| denton-scratch wrote:
| If they do "abolish" leap-seconds, they have to "abolish" UTC as
| well, because UTC is defined based on leap-seconds. Any new
| timescale without leap-seconds needs a new name. Otherwise you
| get the same problem we made with GMT: "Do you mean 14:03 UTC
| _before_ 2035, or 14:03 UTC _after_ 2035? "
|
| So lets call the new timescale NTS. Lots of records and
| timestamps have been made using UTC. So now we'll need a way of
| converting timestamps between UTC and NTS. We already have future
| timestamps in UTC; e.g. "This record must be destroyed at
| midnight UTC, Jan 1 2036". So even after we've switched to NTS,
| we'll still need to calculate UTC, so we'll still need leap-
| second announcements.
|
| Timescales are a deep mess, and as the author notes, having them
| managed by a bunch of treaty organizations is nuts; treaty
| organizations are inherently political (and they move like
| molasses in winter).
| nrclark wrote:
| Leap-seconds are manually added, and don't follow a predictable
| pattern. They're different than leap-years in that respect.
|
| We could all agree to stop adding leap-seconds, and nothing
| would change in 99%+ of all UTC time-handling code. We just
| wouldn't get any more leap seconds. The process of adding them
| is manual anyways, so we could stop it without breaking
| anything.
| tshaddox wrote:
| > so we could stop it without breaking anything
|
| Well, until some sufficiently influential government or
| organization gets annoyed with the discrepancy with solar
| time and comes up with their own correction to the local
| clocks under their jurisdiction. Then at the bare minimum you
| need all the commonly used date/time libraries to be
| updatable with this information. Existing solutions like the
| tz database [0] might already technically support this,
| although I have to imagine that the logistics will be
| annoying at best.
|
| [0] https://en.wikipedia.org/wiki/Tz_database
| jedberg wrote:
| The limiting factor here is that the local jurisdiction
| would have the same computer problems that the rest of us
| do. They also would need a way to update their own clocks
| to reflect their own local time. So presumably it would be
| done within an existing framework, like defining a new time
| zone that is one second further from UTC.
| toast0 wrote:
| The timezone database supports offsets into the seconds,
| although I've heard some applications will not support
| files with such offsets iCalendar feeds that they'd
| otherwise support, so it'd be a bit of a mess still. I
| can't imagine why a country would feel the need to have an
| offset measured in seconds, but there are a lot of
| countries, some of which really don't seem to value global
| consistency, so it wouldn't be terribly surprising.
| Combined with countries that insist on applying DST without
| advanced scheduling, that would be a lot of fun.
| Nullabillity wrote:
| Time zones are wide enough that the error from (missing)
| leap seconds are infinitesimal compared to the quantization
| to the time zone.
|
| Leap seconds are a poor band-aid "solution" to a problem
| that nobody has.
| tshaddox wrote:
| Right, but I'm talking about solar time drift.
| someguydave wrote:
| "Civil time" is an inherently political concept. There is no
| way that humans can coordinate globally on that concept without
| unwieldy treaty organizations.
| BlueTemplar wrote:
| It's also not something that even _needs_ to be coordinated
| globally. This whole thing seems to be a giant confusion
| between the concepts of time and calendar (including
| timezones), and I am not sure why it is still ongoing even
| though the _time_ coordination problem has been seemingly
| solved thanks to atomic clocks for some decades now ??
| mb7733 wrote:
| > If they do "abolish" leap-seconds, they have to "abolish" UTC
| as well, because UTC is defined based on leap-seconds. Any new
| timescale without leap-seconds needs a new name. Otherwise you
| get the same problem we made with GMT: "Do you mean 14:03 UTC
| before 2035, or 14:03 UTC after 2035
|
| If they just stopped adding leap seconds to UTC at some point,
| why would there be any ambiguity about the definition of any
| given UTC time?
|
| > So lets call the new timescale NTS. Lots of records and
| timestamps have been made using UTC. So now we'll need a way of
| converting timestamps between UTC and NTS. We already have
| future timestamps in UTC; e.g. "This record must be destroyed
| at midnight UTC, Jan 1 2036". So even after we've switched to
| NTS, we'll still need to calculate UTC, so we'll still need
| leap-second announcements.
|
| The schedule of leap seconds in the future isn't known, so such
| a timestamp isn't precisely defined yet anyway. Abolishing the
| practice fixes this.
| denton-scratch wrote:
| > If they just stopped adding leap seconds to UTC at some
| point
|
| That seems a fair point; and rather obvious - I'm embarrassed
| thatI don't have an answer.
| sebzim4500 wrote:
| UTC would still have all the leapseconds from the past, it just
| wouldn't have any new ones added.
| mavhc wrote:
| Call it TAI
| https://en.wikipedia.org/wiki/International_Atomic_Time
| myself248 wrote:
| TAI is the only sensible time scale, IMHO. It's monotonic,
| and it gives less than a shit about leap seconds.
|
| Adjust for local display at the time you display it and only
| at the time you display it.
| dark-star wrote:
| > "This record must be destroyed at midnight UTC, Jan 1 2036"
|
| In all practical senses I don't think it would matter much if
| this record is destroyed a few seconds early or late in such a
| case...
___________________________________________________________________
(page generated 2023-01-30 23:01 UTC)