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).
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.
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.
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.
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.
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 ?
> 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.
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.
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.
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.
How is this relevant to this specific discussion ?
You use and synchronize to the same time standard as the world-metrologists do (TAI), the whole issue is that that's not the one that is being disseminated as the article and I already pointed out.
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.
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.
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.
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 360°). 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…)
> 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.
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.
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.
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.
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.
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).
“Civil time” is an inherently political concept. There is no way that humans can coordinate globally on that concept without unwieldy treaty organizations.
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 ??
> 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.
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.
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.
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.
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.
The point is that you get significantly more 'drift' by just moving east or west within a timezone. No government is going to care if the local time at solar noon at a certain location changes a few seconds over the years, given that the time at solar noon changes much more as you move throughout the timezone.
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.?
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.
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.
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.
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.
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...).
We already have a leap year, where we add an extra day every four years. So why could we not adjust the clock every 500 years when it gets out of sync by 20 minutes?
Yeah, I mean thats an option, but I basically expect that to cause a y2k-like level of emergency refactorizations as everyone realizes that their software isn't built for it.
On the other hand, we already have leap seconds. They're not much of a problem.
> On the other hand, we already have leap seconds.
Well, leap seconds are going away, so we don't.
They were never adequate for the long-term anyway, as the "two leap seconds a year" scheme will break down as the earth's rotation slows over the centuries and more and more leap seconds will be needed.
We're talking about an hour time drift over a few thousand years. Does that really matter? It's like caring what Julius Caesar's sense of "morning" or "evening" was. They never really solved any practical problem.
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.
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.
59 comments
[ 0.26 ms ] story [ 116 ms ] thread1 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.
UTC is a (strange) compromise between both: ticking SI seconds like TAI but being kept within 1 second of UT1.
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.
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 ?
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
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.
The current answer is everyone uses UTC, and they keep synchronized by observing the one universally disseminated time, which is UTC.
You use and synchronize to the same time standard as the world-metrologists do (TAI), the whole issue is that that's not the one that is being disseminated as the article and I already pointed out.
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 360°). 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
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.
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.
There is no Radio Shack for marine electronics, but it'd be great if there were.
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.
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).
Adjust for local display at the time you display it and only at the time you display it.
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.
That seems a fair point; and rather obvious - I'm embarrassed thatI don't have an answer.
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...
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.
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
Leap seconds are a poor band-aid "solution" to a problem that nobody has.
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.?
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.
On the other hand, we already have leap seconds. They're not much of a problem.
Well, leap seconds are going away, so we don't.
They were never adequate for the long-term anyway, as the "two leap seconds a year" scheme will break down as the earth's rotation slows over the centuries and more and more leap seconds will be needed.
We're talking about an hour time drift over a few thousand years. Does that really matter? It's like caring what Julius Caesar's sense of "morning" or "evening" was. They never really solved any practical problem.
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.
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
So unless you differ from Earth's calibration on purpose, you won't lose 56 microseconds a day. You'll stay in sync.