What we'd like to have:
1. Use SI seconds
2. Keep in sync with earth rotation
3. Avoid leap seconds
Pick any two:
- UT1: 2, 3 (not 1) [https://en.wikipedia.org/wiki/Universal_Time]
- TAI: 1, 3 (not 2) [https://en.wikipedia.org/wiki/International_Atomic_Time]
- UTC: 1, 2 (not 3) [https://en.wikipedia.org/wiki/Coordinated_Universal_Time]
Who is the "we" who wants to keep "in sync" with the Earth's rotation to such high precision? Obviously having 3:30 pm suddenly become the middle of the night would be bad, but we're talking a delta of 18 seconds spread over almost 50 years... hardly big enough to be called "out of sync" in any noticeable sense. Maybe in a millennium or two we'll lose the cultural context of what "it's 5:00 somewhere" meant, but I'm sure the historians could add a blurb.
Astronomers and navigators. These also were the first people that needed accurate time and first people capable of measuring time accurately, so much of the expertise is in astronomical or naval institutions. This was still very relevant in the 1950s when the modern time systems were being developed.
There is a growing movement in the timekeeping community that agrees that keeping UTC close to UT1 is no longer important and that leap seconds should be abandoned.
I tend to agree. Let astronomers use a rotation-synchronized time. (Aren't they bothered by jumps anyway? They probably need a more gradual skew, which is to say, not SI seconds.) Let everyone else use TAI, and in a few millennia when high noon isn't noon anymore, we'll worry about it then.
Oh by the way, unless you live smack in the middle of a timezone, solar noon isn't clock noon anyway. Plus it gets all jacked up with daylight savings (which should also be abandoned), so the whole notion of leap seconds is farcical on its face.
> Obviously having 3:30 pm suddenly become the middle of the night would be bad, but we're talking a delta of 18 seconds spread over almost 50 years... hardly big enough to be called "out of sync" in any noticeable sense.
And the Julian calendar was 'good enough' for a long time⌠until it wasn't and Pope Gregory XIII had to announce the skipping over of 10 days so that (e.g.) the Spring Equinox actually lined up with the season of spring more accurately.
I understand the sentiment of wanting to simplify things, but kicking the can down the road so it's someone else's problem is wrong in my eyes.
Large parts of the world shift civil time by an hour twice a year. Drifting 1 day every 200,000 years doesn't sound like kicking the can down the road.
If human civilisation still exists by the time we've reached just 1 hour of difference we'll be occupying multiple bodies throughout the solar system, if not further afield, and have to have come up with a new time system anyway. Even the length of a second varies because of relativity.
In 100,000 years when 12pm is in the middle of the night, no one is going to care. It will have been that way for all of living memory, and the fact that noon used to be midday will be nothing more than a historical curiosity. The drift is far too slow for anyone to notice.
What about leap milliseconds? There are plenty of applications that need millisecond accuracy.
Why is it obvious that 3:30 PM bad as the middle of the night is bad?
I'm all for a universal world-wide time. then we'd just have to learn what time is middle of the night for what location, but we have digital aids for that. It solves all timezone bs.
My guess is is that we whine for about a month and then it becomes normal for ie. 14:00 to be middle of the night depending on you location.
I personally tried this for a few weeks: I set my clocks to GMT, and converted everyone else's silly little timezones into one unambiguous number. All I accomplished was memorizing the offset between GMT and local time and getting marginally quicker at the required arithematic to convert between them. It didn't even solve any problems, because a) nobody else was doing it, so, shrug, and b) I immediately lost all context for the earth's rotation, and that turned out to be a massive pain in the ass. I think the very least we can do, though, is get rid of DST.
We already have universal world-wide time: UTC and TAI. You can use these today, and nobody can stop you.
> It solves all timezone bs.
So when does Monday start? 14:00 UTC in your location?
Because you'd get up on Monday and then book a table for after work on Tuesday. The ambiguity of defining "today" would be problematic.
Now sure people who work night shifts have that, but it's a small number of people and a small number of services that are open 24/7.
I don't specifically care about earth's rotation, but as a diurnal creature whose internal body clock synchronizes to the sun, I definitely care about the rhythms of natural light. The whole reason clocks were invented was to help people more precisely measure the day-night cycle.
So the question really becomes, "Who is the 'we' who wants to have a more theoretically pure timekeeping system that gets worse and worse at its primary purpose?" Turns out that's a pretty small audience.
If the drift is 18s over 50 yrs then it doesn't address your issue to any noticable degree throughout your life.
Nor that of your children, grandchildren etc etc, as the change is gradual enough that nobody would notice. The only way to get a significant difference is by somehow sleeping for thousands of years (1k would be 6 minutes, which would still be impossible to tell with human senses).
It really is a pretty pointless solution to a non-existing problem.
Just stick with TAI and convert times to UTC when displaying them is required. The real crap here is the C and POSIX time_t type and its related functions, which are massively out of date (like the 70% of the C standard library). The ISO C standard committee is way too scared of breaking stuff, and when they add something is often utter garbage (look at the whole _s functions fiasco in C11).
> Just stick with TAI and convert times to UTC when displaying them.
That may not be suitable when you want to represent an exact point in time years into the future. Youâre usually not interested in the exact number of elapsed seconds (TAI) in that case, but want to represent e.g. 2031-08-03T:00:00:00Z exactly.
The solution is to use different data types for elapsed time and for calendrical/time-of-day time. Software developers need to learn that those are not equivalent, and libraries, databases etc. need to provide appropriate data types that make the distinction clear.
If you want an UTC time in the distant future, more than a few years away, then you cannot know how much time will pass until then.
The leap seconds are inserted randomly, you cannot predict when this will happen.
The UTC time is known only for the past, more precisely for the past 60 years.
For the future beyond a year, the UTC time is unknown.
On the other hand TAI, which is a real time, not a conventional quantity determined by political decisions, is known both for the past and for the future.
You are right that e.g. for scheduling meetings in the future, a different type must be used, whose meaning is "the time moment that will have this official name by then". This time should not be used for computing time differences with a resolution smaller than a day, before it becomes close enough to the present.
The problem with rendering TAI as UTC is you can't do it for future dates because you don't know how many leap seconds will have been added by then. For future dates you can either:
- store TAI: you'll always know how many SI seconds in the future it is, but you won't be able to accurately render UTC,
- store UTC timestamp: you'll always know what the time on the clock will be when the event happens, but you won't be able to accurately calculate how many seconds in the future it is.
The alternative is to ditch UTC. Make all wall clocks tick in SI seconds and render TAI dates in local time. This will always be correct. The only downside is you won't be able to accurately predict what position the Sun is in the sky when the event happens. But is this actually important?
Rendering future times as local time already has a problem where the timezone (DST) could potentially change.
orâŚ
if you want the future time stamp to be âexactly x secondsâ in the future you can store a tuple of the TAI time stamp of when you create the data point, and the SI seconds into the future from that time and then render it as appropriate for the audienceâs level of understanding
And if you want the future time stamp to be not actually a time stamp but a time of day on a calendar date, then you store a tuple of the TAI creation time, the UTC date you want it to be in the future
Because you can never ever be sure of the future, by keeping the time you make the assumptions you can at least either calculate the correct answer or fix the data later when you find out something has changed.
TAI is for timekeeping.
UTC is for calendars.
They should be scared of breaking stuff! If newer standards break things, those newer standards are unlikely to get wide adoption, which prevents actual progress.
In any case, while the POSIX and C standards need to accommodate atomic time, that's not enough. The software on top needs to switch to atomic timestamps too.
C++ is being adding basically both the kitchen and the sink for years now and still it hasn't broken anything. If anything, lots of warts have been removed now. This whole reasoning doesn't hold when the ISO C standard adds half-assed, optional rubbish to the C standard only to deprecate it the next release.
The ISO C can't create a newer, saner C string library or a more useful time library, but it finds the time to devise and release crap like VLA, threads.h or _s functions. Meanwhile, C++20 has stabilized std::chrono::tai_clock, which works on all major operating systems, and does not break anything.
As far as I remember from earlier discussion, the reason that problems arise is that the posix standard defines a "day" as 86400 seconds, so leap seconds need to be erased from history after they've happened. This doesn't make a lot of sense; on March 1st, we don't start pretending that February 29th never happened.
The problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well.
Given that we don't know when there will be leap seconds in the future, this conversion is imposible if we want to take leap seconds into account.
So the solution is to either ignore leap seconds (as posix currently does) or have a regular rate of leap seconds (just like leap years). Unfortunately, the rotation of the earth is are not regular enough for a fix rate.
At the scale of a human life, leap seconds are completely irrelevant if you want to know the position of the sun.
So it is bizar that our civil time has leap seconds. Looking back, that seems to be a historical mistake.
> The problem is that posix needs the conversion between 'posix time' (seconds since 1970) and the split out year/month/day/hour/minute/second format to work for the future as well.
> Given that we don't know when there will be leap seconds in the future, this conversion is impossible if we want to take leap seconds into account.
The conversion is impossible anyway. We don't know what the calendar will look like in the future. That isn't a problem that can be solved by any means.
Well, POSIX time is an additional layer of stupidity, but it certainly not the only source of problems; notably these GPS/GNSS related problems do not have anything to do with POSIX time
There is no problem with GPS time, only with converting from GPS time to POSIX time or some other leap-second affected time.
>on March 1st, we don't start pretending that February 29th never happened.
Speak for yourself.
TAI sounds perfectly reasonable for most systems and should be the default IMO - only when displayed to humans do we really need to care about syncing up with the earth's rotation.
We had a leap second bug on the options trading desk I worked on that brought down our system. As market makers, we had an obligation to keep providing liquidity so this was a serious issue and exposed us to fines.
Our exchange co-located data centers used GPS for precisely synchronized timestamp generation but the firmware on some of the GPS hardware had a bug and failed to take into account a leap second. When that leap second was to be inserted, they became out of sync by a second.
We generated spot price feeds from each location and a component that consumed these feeds would check to ensure that they were not stale (any data more than 0.5 sec old could not be used as an input for pricing and trading). Well, a lot of exchange feeds started looking stale, and our system stopped quoting on said exchanges.
First there were some murmurs from the traders and within minutes the entire room hit a crescendo of panic. It took, I think, the better part of an hour to debug.
Can you provide the model of the GPS hardware? I work in the same industry and have set up multiple NTP / PTP timer servers that have never failed to account for leap seconds. It's almost always the downstream software that crashes. See the 2012 leap second insertion as an example.
How did you resolve it?
They just needed to add leap seconds to the hardware timestamp after they debugged it.
Worth mentioning, there's an ongoing debate about removing leap seconds, as they seem to cause more trouble than benefit they bring (UT1 and UTC being in sync).
Personally I've dealt with some unit tests around simultaneous use of multiple timezones (we had to show the timestamps in the local timezone of the respective event). One day a good chunk of them stopped working for no apparent reason.
After a lot of head scratching, I figured out an update of tzdata was responsible for it, since it added new planned leap seconds. Our underlying library was properly taking the leap second into account, but the test conditions weren't.
At my work we have a system where dates are in a local timezone, where the timezone depends on the data ingress point, but times are in New York local time.
So many bugs occur when juggling 2 or 3 timezones simultaneously.
I won't name it, but I can guess where you work, as the place I once worked had the same problem and surely not many places have made the same mistake.
Worst is where the NY local time jumps back due to DST and you have two actual points in time represented by the same numerical NY local time. That manifests itself as an hour long gap in the data for the Australian stock exchanges!
It shouldn't be problematic as long as the exchange stops trading for at least 2 out of 24 hours, since no DST shifts can bridge the gap and cause ambiguity.
24 hour exchanges are hosed though
Where do you work now and what mistakes have they made? :P
Offered for perspective/interestingness, not as an argument:
For anyone wondering why it matters so much that time be precisely linked to the rotation of Earth, I'll note that time is a fundamental component of navigation. When you do celestial nav you make corrections down to the second, including accounting for the number of seconds your watch gains or loses. So it's not just about putting timestamps in a database. There's a straight line (a rhumb line? har har) from "what time is it" to "where are we" and in that context losing a second means you get a different longitude. Because time in this setting isn't really time--it's an indication of how far east or west of the prime meridian the sun is.
Is there any practical navigation use case that needs enough precision to not be off 27 seconds from Earth's rotation and unable to use GPS?
Thanks, this helped me adjust my mental model!
So many comments on here asserting that leap seconds are bad and should be abandoned and that it would be simpler if they didnât exist, butâŚ
You realize this is about the GPS system, right? The thing about GPS satellites is that they are in space, orbiting around the earth. If the earthâs rotation speed changes their orbital speed doesnât (not immediately, anyway).
GPS absolutely needs to adjust for the variable rotational speed of the earth - otherwise the GPS coordinate grid would gradually move relative to the surface of the earth.
So GPS doesnât exactly need leap seconds but it really does care about how long a rotation of the earth takes which⌠amounts to the same thing.
> So GPS doesnât exactly need leap seconds but it really does care about how long a rotation of the earth takes which⌠amounts to the same thing.
I don't think this is right. GPS explicitly uses a timebase that does not include leap seconds [1].
On the subject of the article: my modest and very reasonable proposal is that we apply a leap second every six months without fail, dithering between positive and negative leap seconds so as to remain close to sidereal time. That way we would flush out bugs every six months and wouldn't have them accumulate and hit us all at once.
Or we could be boring and use TAI or GPS time as the system clock every where and apply leap second corrections when we go from the system clock (currently UTC) to local time.
[1] https://en.wikipedia.org/wiki/Global_Positioning_System#Time...
I mean, the article is literally about GPS satellites transmitting leap second data as part of their messages. So yes, the basic clock is just counting seconds but leap seconds are a pretty important component of the GOPS model.
So, GPS involves a few things: precise clocks that can be used to triangulate position; a model of where the satellites containing the clocks are in space; and a model of where the earth is in space.
UTC has basically the same inputs (the clocks are on the surface instead of in orbit, but one of the main time labs [NIST] is in Colorado and its altitude needs to be taken into account), but the calculations and logistics, the timebase of the model, are all very different.
So you canât derive UTC from the GPS ephemeris, because thereâs a human in the loop who decides when leap seconds happen. So GPS needs to include UTC as a separate signal, alongside the ephemeris and everything else.
(In fact, if I remember correctly, GPS includes nanosecond-level corrections between GPS time and UTC, because atomic clocks are not completely perfect.)
> GPS absolutely needs to adjust for the variable rotational speed of the earth
Sure, but that's a spacial thing, not something that's relevant to timekeeping. (There's technically a change in relativistic time dilation, but it's less than a rounding error - about five millimeters per second at the equator makes 1.000000000002388402 versus 1.000000000002388457 if I've got my math right. (The relativistic time dilation from the earth's rotation is itself a rounding error.))
And when youâre using GPS to find your location on the surface of the earth⌠spatial things matter, right? GPS is for figuring out your location, not what time it is.
You can use it to figure out what time it is, but thatâs a side effect not the goal.
Sorry, but your comment is just nonsense. :( GPS time doesn't include leapseconds: It's effectively TAI with a different offset.
GPS indeed has to correct for all sorts of orbital stuff, but that is done with equations on top of a stable atomic timebase. (And it has to be that way-- each satellite's orbital parameters are different).
Knowing your location relative to the satellites is only so useful if youâre actually standing on the surface of the earth (or trying to fly to a particular point on its surface). You also need to know which way the earth is facing right now. And to do that you need to know how many times itâs gone round since some reference time - which varies, but amounts to ânumber of days taking into account smeared leap secondsâ
That isn't at all how the ephemeris data is represented in GPS. The satellite locations/headings are specified in earth-fixed geocentric coordinates. So, it's as if the earth was sitting still and the satellites were swarming around it.
The effect of earths very slow changes in rotation speed would effect the accuracy, but the ephemeris data is periodically updated based on observations of satellite locations by ground stations, there are many larger sources of positioning error than changes in the earth's rotation. This is also why first fix from a cold (memory wiped or long offline) receiver takes a long time even when it knows your location, unless you have AGPS (e.g. via the cell network): it doesn't know what satellites are overhead and it has to do a brute force search before it can find the signals and download the ephemeris data.
(There is a side channel that carries info on leap seconds, so that civil timing stuff can derrive UTC from the GPS time. ... but that isn't used by GPS itself at all).
Here is a nice page that shows the current GPS time and notes that it does not include leap seconds: http://www.leapsecond.com/java/gpsclock.htm
(One of) the biggest pains with leap seconds is they are so infrequent and so I/O-bound, that they are almost impossible to test. What is less functional than relying on a random change in a radio signal below the noise floor coming through dedicated hardware, which is finicky and doesn't work well indoors (E-coated glass windows? Fuggetaboutit).
I think one thing that could have be easily done to help is emit leap-sub-seconds (100-500ms) more frequently, so we would have more chances to detect bugs per year. Alas, leap seconds are baked in as int8 so that's never gonna happen. That's also totally not the mindset when these systems were designed, which is kind of my point. The right kind of forethought could have avoid much of this pain.
Option 1: We have 2 time standards out of sync. Let's make an announcement yearly-ish and add 1 second of offset that everything has to obey.
Option 2: We have 2 time standards out of sync. Let's continuously track the offset to (whatever precision) and this offset is just always part of the correction (like we do time zones), rather than this value which you just assume is static 99% of the time.
This could lead to an interesting situation, where in June of 2029 a multitude of double-spending attacks are initiated on various banking/financial software across the world, with the attack lasting a few seconds in total. What a headline that would be... Of course this depends on specific implementation, but I can see how this could happen to a wide array of implementations.
Looking at how banks handled these kind of issues in the past, they'll shut down all operations for these few seconds and throw away anything that still came in these seconds as invalid.
It sucks for their customers and partners, but that would be a decent conservative option I think.
Somebody should have told the financial institutions in Batman: The Dark Knight Rises that throwing away very obvious unwanted transactions was an option!
On one side it might not be a good idea to have actual actionable and efficient criminal plans enacted in popular fiction.
On the other side, it seems to be a disservice to the community to have stupid ideas widely spread around. It's hard to balance for sure.
Previous discussion: https://news.ycombinator.com/item?id=27944776
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.