Leap Smear(developers.google.com)
developers.google.com
Leap Smear
https://developers.google.com/time/smear
8 comments
> It makes me angry that programmers feel that they "own" the concept of time measurement
Programmers feel that they "own" pretty much every social construct, by virtue of the fact that it is their job to encode those constructs into interfaces and databases. See the famous "falsehoods programmers believe about X" [1] --- and I'm sure you'll like this one about time [2].
[1] https://github.com/kdeldycke/awesome-falsehood
[2] https://infiniteundo.com/post/25326999628/falsehoods-program...
Programmers feel that they "own" pretty much every social construct, by virtue of the fact that it is their job to encode those constructs into interfaces and databases. See the famous "falsehoods programmers believe about X" [1] --- and I'm sure you'll like this one about time [2].
[1] https://github.com/kdeldycke/awesome-falsehood
[2] https://infiniteundo.com/post/25326999628/falsehoods-program...
> It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds.
Your assumption of what happens with smearing isn't accurate. Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system. The leap second isn't being removed at all: it's simply being applied over the course of an extended period of time rather than all at once. There's virtually no practical reason that any system needs to have a single moment where a leap second is observable. The leap second is still respected and applied.
Besides the point that other commenters made about dates in the future being unrepresentable with a timestamp like you describe, it's unnecessary: systems already compute time correctly with or without leap seconds, and converting between an adjusted date and one fixed to the epoch is fast and straightforward.
But moreover, what's your goal? If you're counting seconds, everything at the application layer that needs to present dates and times (and durations, and intervals) to humans then needs to be aware of every leap second. You trade one problem (date math that considers leap seconds) for another especially bad one (every date formatting library needs to have complete knowledge of leap seconds). I don't know about you, but the last thing I want is every programmer in the world needing to get leap seconds right instead of the few thousand people that maintain the runtimes and the OSs.
Your assumption of what happens with smearing isn't accurate. Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system. The leap second isn't being removed at all: it's simply being applied over the course of an extended period of time rather than all at once. There's virtually no practical reason that any system needs to have a single moment where a leap second is observable. The leap second is still respected and applied.
Besides the point that other commenters made about dates in the future being unrepresentable with a timestamp like you describe, it's unnecessary: systems already compute time correctly with or without leap seconds, and converting between an adjusted date and one fixed to the epoch is fast and straightforward.
But moreover, what's your goal? If you're counting seconds, everything at the application layer that needs to present dates and times (and durations, and intervals) to humans then needs to be aware of every leap second. You trade one problem (date math that considers leap seconds) for another especially bad one (every date formatting library needs to have complete knowledge of leap seconds). I don't know about you, but the last thing I want is every programmer in the world needing to get leap seconds right instead of the few thousand people that maintain the runtimes and the OSs.
I'm not actually complaining about smearing, I was just using the opportunity to complain about the proposal to abolish leap seconds:
https://en.wikipedia.org/wiki/Leap_second#International_prop...
https://en.wikipedia.org/wiki/Leap_second#International_prop...
[deleted]
>Before and after a smear, the time reported by a smearing system would match a (synced) non-smearing system.
>it's simply being applied over the course of an extended period of time rather than all at once.
I don't follow, how can both be true? If we're averaging the differnce over a period of time there has to be a difference between systems that smear times and systems that don't. Obviously these different measurements will converge like at the end of a year but how do they sync otherwise?
>it's simply being applied over the course of an extended period of time rather than all at once.
I don't follow, how can both be true? If we're averaging the differnce over a period of time there has to be a difference between systems that smear times and systems that don't. Obviously these different measurements will converge like at the end of a year but how do they sync otherwise?
There's only a difference while the smear is incomplete, and the smear lasts (usually) 24 hours.
Imagine you split the leap second in half. Instead of applying it at T+0, you skip forward 500ms at T+0 and another 500ms at T+1. Now imagine doing the same thing, but 1/86400 of a second every second from noon to noon. You can imagine doing it at even smaller increments more frequently than once per second.
At the start, both systems are in sync. One day later, both systems are in sync. You've simply applied the delta incrementally rather than all at once.
Imagine you split the leap second in half. Instead of applying it at T+0, you skip forward 500ms at T+0 and another 500ms at T+1. Now imagine doing the same thing, but 1/86400 of a second every second from noon to noon. You can imagine doing it at even smaller increments more frequently than once per second.
At the start, both systems are in sync. One day later, both systems are in sync. You've simply applied the delta incrementally rather than all at once.
>At the start, both systems are in sync. One day later, both systems are in sync.
That's what I said? So they would be out of sync otherwise.
Edit: Hold up, after rereading the thread I think we're all talking past each other here. I understand how time smearing works but when OP said they would sync up I read that as meaning they would somehow always sync up not just when they converge every 24 hours and the end of the year. But now I understand that's probably what OP meant.
That's what I said? So they would be out of sync otherwise.
Edit: Hold up, after rereading the thread I think we're all talking past each other here. I understand how time smearing works but when OP said they would sync up I read that as meaning they would somehow always sync up not just when they converge every 24 hours and the end of the year. But now I understand that's probably what OP meant.
The extra/missing second is averaged over the 24 hours surrounding that second. The difference in times between smearing and non-smearing systems never exceeds 500 milliseconds, and their difference in clock "speeds" is a bit under 12 ppm.
> the obvious solution is computers should simply measure seconds since the epoch
Obvious solutions are usually wrong, and this one is no exception.
How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format? Since leap seconds are only announced 6 months in advance, any number you pick right now could be off by as much as 15-20 seconds in either direction. Conversely, as those leap seconds are decided upon, the human-readable representation of that number could change unpredictably.
Obvious solutions are usually wrong, and this one is no exception.
How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format? Since leap seconds are only announced 6 months in advance, any number you pick right now could be off by as much as 15-20 seconds in either direction. Conversely, as those leap seconds are decided upon, the human-readable representation of that number could change unpredictably.
> How do you represent a time which lies well in the future, like "January 1, 2030, midnight GMT" in that format?
Problem is that "January 1, 2030, midnight GMT" is not time moment itself, it is just human label for some time moment. Time is a physical quantity measurered in seconds. We do not know which time will be represented by label "January 1, 2030, midnight GMT" in the future, because that might change. That is why such representation it is unusable as a timestamp.
Problem is that "January 1, 2030, midnight GMT" is not time moment itself, it is just human label for some time moment. Time is a physical quantity measurered in seconds. We do not know which time will be represented by label "January 1, 2030, midnight GMT" in the future, because that might change. That is why such representation it is unusable as a timestamp.
And that's ridiculous. Outside of special cases like changes to DST rules, people expect to be able to perform arithmetic on dates and get results which don't vary over time, no more than other physical measurements and operations change over time.
As long as you can afford a half-minute precision for an event 8.5 years ahead, you still can assume that simple datetime arithmetic works. This is ignoring the complexity of the reality.
If you need a better precision, you store your date as a label saying "local midnight of January 1st 2030", and adjust its mapping to a particular number of seconds since epoch as time passes, or maybe do something even more complex. This is adjusting to the complexity of the reality.
The third way, mandating the reality to not be complex, is not available.
If you need a better precision, you store your date as a label saying "local midnight of January 1st 2030", and adjust its mapping to a particular number of seconds since epoch as time passes, or maybe do something even more complex. This is adjusting to the complexity of the reality.
The third way, mandating the reality to not be complex, is not available.
It's not ridiculous. One is a measurement of linear time, the other is a series of context-sensitive human labels tied to planetary movements. Conceptually they are not the same thing, even though we try very hard to make them the same.
Well, you can't, because GMT is not well-defined. It's been through numerous revisions, so that if you want to specify a time in GMT, you also need to state which revision of GMT you are using. GMT is now an obsolete timescale.
GMT has generally been some form of "Mean Solar Time at Greenwich". If you're specifying a time well in the future, then for the same reason as UTC in the future is ill-defined, so is Mean Solar Time at Greenwich. If the speed of the Earth's rotation has changed (it will have) then there's no way of knowing the numer of seconds between now and "January 1, 2030, midnight GMT".
The term is nowadays used to refer to UTC, but in a handwavy way. The BBC refers to all its time announcements as being something "GMT", which they enunciate in a smug, jingoistic tone of voice. It sickens me (and I'm a brit).
Here's an excellent article detailing the relationships between different timescales, paying particular attention to the "sordid history of GMT".
https://www.ucolick.org/~sla/leapsecs/timescales.html
GMT has generally been some form of "Mean Solar Time at Greenwich". If you're specifying a time well in the future, then for the same reason as UTC in the future is ill-defined, so is Mean Solar Time at Greenwich. If the speed of the Earth's rotation has changed (it will have) then there's no way of knowing the numer of seconds between now and "January 1, 2030, midnight GMT".
The term is nowadays used to refer to UTC, but in a handwavy way. The BBC refers to all its time announcements as being something "GMT", which they enunciate in a smug, jingoistic tone of voice. It sickens me (and I'm a brit).
Here's an excellent article detailing the relationships between different timescales, paying particular attention to the "sordid history of GMT".
https://www.ucolick.org/~sla/leapsecs/timescales.html
Are you describing a celestial event, or scheduling a New Year’s party for humans? For the former, you are probably already using TAI (or GPS). For the latter, use an ISO 8601 string, and call it Europe/London instead of GMT. As you recognize - the mapping of human dates to celestial time is unstable. Don’t pretend it is by using a number until you need to.
For the majority of people solar noon does not match civil noon. Today solar noon at my location was at 12:27.
If you live at the equator walking 500 metres east or west will put you a second off solar noon. That distance is reduced the further you get away from the equator.
Abolishing leap seconds would be unnoticeable for the majority of the population for thousands of years. At that point it could be fixed in one go or timezones could be slowly moved.
Those that would notice the change probably need sub-second accuracy that leap seconds just make more complicated.
If you live at the equator walking 500 metres east or west will put you a second off solar noon. That distance is reduced the further you get away from the equator.
Abolishing leap seconds would be unnoticeable for the majority of the population for thousands of years. At that point it could be fixed in one go or timezones could be slowly moved.
Those that would notice the change probably need sub-second accuracy that leap seconds just make more complicated.
The leap second is not for majority of people, but for scientists and astronomers so that they can use UTC.
Cf. https://www.nist.gov/pml/time-and-frequency-division/leap-se...
> We have had to invent a way of compensating for the variable rate of spin such that "midday" is still the middle of the day and "midnight" is still the middle of the night.
Just granularity of timezones causes 30min offset of civil 'midday' and 'midnight' to astronomical one (more with political borders of timezones instead of strict 15°). DST adds another 1h of offset.
If we want adjustments so these concepts would not slowly drift away, we can just shift timezones once per few thousand years.
Just granularity of timezones causes 30min offset of civil 'midday' and 'midnight' to astronomical one (more with political borders of timezones instead of strict 15°). DST adds another 1h of offset.
If we want adjustments so these concepts would not slowly drift away, we can just shift timezones once per few thousand years.
> It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. The definition of unix time excluding leap seconds is really the origin of this nonsense, and it has always seemed to me that the obvious solution is computers should simply measure seconds since the epoch. Wikipedia describes this version as the "TAI-based variant" of Unix Time, and if we all used it, computers wouldn't even have to care about leap seconds, and conversion to standard time display could be done in userland, accounting for leap seconds in the process.
That's not fair to programmers: the definition of a leap second is up to an international organisation (IERS), and more importantly leap seconds added in 2020 couldn't have been known by anyone in the 1970s. Leap seconds are added only six months before they are to take effect, as per wiki (https://en.wikipedia.org/wiki/Leap_second): "Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap seconds are irregularly spaced and unpredictable."
That's not fair to programmers: the definition of a leap second is up to an international organisation (IERS), and more importantly leap seconds added in 2020 couldn't have been known by anyone in the 1970s. Leap seconds are added only six months before they are to take effect, as per wiki (https://en.wikipedia.org/wiki/Leap_second): "Because the Earth's rotation speed varies in response to climatic and geological events, UTC leap seconds are irregularly spaced and unpredictable."
No clock is perfect. Computer clocks and data types assume exactly the same amount of seconds per day. Adding leap seconds to clock code makes it unnecessarily complicated. Leap days have a well behaving algorithm, but leap seconds require a lookup to a table that changes over time. Also maybe people look at the raw data for dates. If we stored a different format, inevitably people would store both forms, and every time you programmed you would have to ask which form is it in.
TAI is for things like GPS and missiles where super accurate timekeeping is crucial. Most computers are crap at keeping time and quickly drift. They make calls to central time servers that are better at time keeping, that is where the smear occurs. For most computers their normal drift is in the same order of magnitude as the smear, so it’s not noticeable. Also most distributed programs realize time stamps are not always correct, and when temporal ordering is crucial other methods are used.
TAI is for things like GPS and missiles where super accurate timekeeping is crucial. Most computers are crap at keeping time and quickly drift. They make calls to central time servers that are better at time keeping, that is where the smear occurs. For most computers their normal drift is in the same order of magnitude as the smear, so it’s not noticeable. Also most distributed programs realize time stamps are not always correct, and when temporal ordering is crucial other methods are used.
[deleted]
The feeling of "ownership" is likely the result of being the ones asked to "solve" it. Or possibly being the only group of people able to solve it in the ubiquitous software context.
Provide better requirements to result in the solution you actually want.
Provide better requirements to result in the solution you actually want.
My understanding is that the rate of earth's spin is "constant" (actually it is slowly decreasing on geologic time scales) but the orbit of the earth is not circular and a revolution around the sun doesn't match with a full number of earth rotations.
That is not correct. Positive leap seconds are caused by Earth's rotation rate slowing. Recently the Earth has begun to rotate slightly faster, possibly caused by climate change, which may mean a negative leap second is necessary.
https://en.wikipedia.org/wiki/Earth%27s_rotation
https://en.wikipedia.org/wiki/Earth%27s_rotation
This is the worst of all possible worlds.
Instead of a disruptive event that lasts 1 second, it lasts 86400 seconds. All throughout those 86400 seconds you are out of sync with everybody else in the world, except those few you might have bullied into matching you.
The best solution is to simply cut UTC loose from astronomical time. Anybody who cares about astronomical time--people calculating orbits and telescope directions--are not using UTC anyway, and know how to convert from TAI when they need to.
Over two centuries, UTC might drift a minute off of astronomical time. A UTC2 in 2106 (when 32-bit unsigned count of seconds since 1970 rolls over) would be a good point to plan for a correction, if one starts to seem warranted by then.
In the meantime, you just treat UTC as if it really did represent astronomical time, and with the TAI crowd out of the building, no one is left to care about the difference.
It is easy to institute the change: simply stop declaring leap seconds. At each international treaty-scheduled opportunity, say "nope". And announce you will always say "nope".
Until the correct solution is ratified, getting your leap second over-with in a second is the next best thing.
Instead of a disruptive event that lasts 1 second, it lasts 86400 seconds. All throughout those 86400 seconds you are out of sync with everybody else in the world, except those few you might have bullied into matching you.
The best solution is to simply cut UTC loose from astronomical time. Anybody who cares about astronomical time--people calculating orbits and telescope directions--are not using UTC anyway, and know how to convert from TAI when they need to.
Over two centuries, UTC might drift a minute off of astronomical time. A UTC2 in 2106 (when 32-bit unsigned count of seconds since 1970 rolls over) would be a good point to plan for a correction, if one starts to seem warranted by then.
In the meantime, you just treat UTC as if it really did represent astronomical time, and with the TAI crowd out of the building, no one is left to care about the difference.
It is easy to institute the change: simply stop declaring leap seconds. At each international treaty-scheduled opportunity, say "nope". And announce you will always say "nope".
Until the correct solution is ratified, getting your leap second over-with in a second is the next best thing.
No, I think stock exchanges going down is worse than smearing. The <500 msec difference between smeared time and UTC is barely noticeable due to network latency.
Stock exchanges shutting down for a few seconds to let the storm abate is pretty benign. Exchanges stop trading, for much longer, for a variety of good reasons. "Time Standards are insane" is one such good reason among many.
The only real harm that can arise is if trading halts for some users but not others. If all trading stops, the field remains level.
The only real harm that can arise is if trading halts for some users but not others. If all trading stops, the field remains level.
[deleted]
This sounds like a potential flash trading arbitrage play between code that implements the smear and code that doesn't. As in a whole bunch of market making institutions and retail traders are going to be a few hundred milliseconds slow off the mark that day?
Speculating you may get a few extra tries guessing a PIN as well given the time based window shift, we might be able to see evidence of the drift in internet routing tables and back off penalties, the same might go for some buggy rate limiting implementations for web requests, where the number of requests you can get through in a "minute" will overflow a fixed integer value. I'm sure the blockchain DeFi people are already hunting through smart contracts for potential vulnerabilities on it.
This is a really interesting problem, even if these ideas are speculative, it's where I'd go looking for vulns.
Speculating you may get a few extra tries guessing a PIN as well given the time based window shift, we might be able to see evidence of the drift in internet routing tables and back off penalties, the same might go for some buggy rate limiting implementations for web requests, where the number of requests you can get through in a "minute" will overflow a fixed integer value. I'm sure the blockchain DeFi people are already hunting through smart contracts for potential vulnerabilities on it.
This is a really interesting problem, even if these ideas are speculative, it's where I'd go looking for vulns.
Why are we happy to have clocks drift by a second? Why not have leap milliseconds or leap nanoseconds? Or conversely leap minutes or hours?
1 second changes seem arbitrary
1 second changes seem arbitrary
Second is the SI base unit of time. Whether it makes sense is a different question, but it is not "arbitrary".
Why? Why don’t we use TAI or GPS time for generic world wide coordinated computer time?
Because we want to unambiguously refer to times in the future?
[edit]
It would of course have been possible to have NTP be based of of TAI rather than UTC (and that might have been a good idea), but it still begs the question of what any POSIX operating system will do given that posix timestamps are leap-second adjusted. And the reason that POSIX timestamps are leap-second adjusted is so that 2628198843 has always, and will always represent 2053-04-13T23:14:03Z. For better or worse, humans have standardized on UTC, so machines that expect to interact with humans must also do so.
[edit]
It would of course have been possible to have NTP be based of of TAI rather than UTC (and that might have been a good idea), but it still begs the question of what any POSIX operating system will do given that posix timestamps are leap-second adjusted. And the reason that POSIX timestamps are leap-second adjusted is so that 2628198843 has always, and will always represent 2053-04-13T23:14:03Z. For better or worse, humans have standardized on UTC, so machines that expect to interact with humans must also do so.
I would argue UTC timestamps are still ambiguous, just in a different way.
How many seconds between now and 2038-01-01T00:00:00?
It's impossible to say because we can't predict future leap seconds.
Many uses of future times are always going to be ambiguous because humans care about timezones, which can change at any time.
How many seconds between now and 2038-01-01T00:00:00?
It's impossible to say because we can't predict future leap seconds.
Many uses of future times are always going to be ambiguous because humans care about timezones, which can change at any time.
That’s not ambiguous though. The answer is, unambiguously, that we don’t know how many seconds there will be. But we can still agree to meet at that time, assuming we will both continue using the same time standard.
I get OPs point though - coming from an outsiders perspective I would have thought that a key feature of a time format would be to know how much time there is between two other times.
The standard for communicating time between humans lacks this feature for times more than a year in the future. That computers (which interface with humans) implement this standard faithfully is a feature, not a bug.
I agree it should be implemented but it could be implemented differently. Just like zoned datetimes are represented as a UTC time + timezone. UTC could be represented as TAI timestamp + leap seconds.
That is true, but again humans.
Humans will be less bothered by you being off by 10s of seconds for "how many seconds until X" where X is multiple years in the future than they will be where X is a minute in the future. Any timestamp created today may be used far in the future, but durations are (by their very nature) transient. Even if you were to do a sleep(nominal seconds until 2038) the computer is likely to reboot before the interval expires, mooting any issues.
Humans will be less bothered by you being off by 10s of seconds for "how many seconds until X" where X is multiple years in the future than they will be where X is a minute in the future. Any timestamp created today may be used far in the future, but durations are (by their very nature) transient. Even if you were to do a sleep(nominal seconds until 2038) the computer is likely to reboot before the interval expires, mooting any issues.
It depends on what you mean by "computer time".
We _do_ use it on some "computers":
> "The Society of Motion Picture and Television Engineers (SMPTE) video/audio industry standards body selected TAI for deriving timestamps of media.[77] IEC/IEEE 60802 (Time sensitive networks) specifies TAI for all operations. Grid automation is planning to switch to TAI for global distribution of events in electrical grids. Bluetooth mesh networking also uses TAI.[78]"
(from https://en.wikipedia.org/wiki/Leap_second#Workarounds_for_le... )
We _do_ use it on some "computers":
> "The Society of Motion Picture and Television Engineers (SMPTE) video/audio industry standards body selected TAI for deriving timestamps of media.[77] IEC/IEEE 60802 (Time sensitive networks) specifies TAI for all operations. Grid automation is planning to switch to TAI for global distribution of events in electrical grids. Bluetooth mesh networking also uses TAI.[78]"
(from https://en.wikipedia.org/wiki/Leap_second#Workarounds_for_le... )
I know. I know. It's bananas. People keep making time more and more complicated. Different kinds of smears, changes in the dates of daylight savings times, timezone shapes influenced by geography instead of the amount of light.
Honestly, time is complicated. Even on Earth, where we rarely have to address synchronization errors due to relativistic effects.
Users care very much about time preserving ordering of events and synchronization of events at disparate locales. They get grumpy if, say, their alarms start going off at what the local restaurants think is 1PM instead of noon because the national government passed a law starting (or stopping) observance of Daylight Savings this year. Similarly (though it's a slower-rolling error), they get grumpy if their alarms start firing at 11:59 and 59 seconds, 11:59 and 58 seconds, etc. when they have them set for noon.
Time is, ultimately, a human construct and software management of it is beholden to the need to get it right from the user's point of view.
Users care very much about time preserving ordering of events and synchronization of events at disparate locales. They get grumpy if, say, their alarms start going off at what the local restaurants think is 1PM instead of noon because the national government passed a law starting (or stopping) observance of Daylight Savings this year. Similarly (though it's a slower-rolling error), they get grumpy if their alarms start firing at 11:59 and 59 seconds, 11:59 and 58 seconds, etc. when they have them set for noon.
Time is, ultimately, a human construct and software management of it is beholden to the need to get it right from the user's point of view.
You were downvoted unjustly. I think your opinion is mostly valid, but I think people undervalue simplicity because they underestimate knock-on effects of their decisions.
> Why don’t we use TAI or GPS time for generic world wide coordinated computer time?
I think that is valid as long as systems are talking to systems, but the interface with the world (when things are happening in the world) is where the solar day or year is still relevant.
I'm sort of joking, but watching Interstellar made me kinda cringe about what interstellar gravity wells is going to do to time-keeping, even if we use something like an atomic clock to keep time.
We will slowly get better at this until we discover something new, but the switch doesn't mean anything until the costs outweigh the change.
And the leap second is going look like 46-45 BCE[1].
[1] - https://www.youtube.com/watch?v=fD-R35DSSZY
I think that is valid as long as systems are talking to systems, but the interface with the world (when things are happening in the world) is where the solar day or year is still relevant.
I'm sort of joking, but watching Interstellar made me kinda cringe about what interstellar gravity wells is going to do to time-keeping, even if we use something like an atomic clock to keep time.
We will slowly get better at this until we discover something new, but the switch doesn't mean anything until the costs outweigh the change.
And the leap second is going look like 46-45 BCE[1].
[1] - https://www.youtube.com/watch?v=fD-R35DSSZY
In some polls I've seen there's plurality support for "permanent 'summer time'". People don't seem to care much that noon in civil time maps exactly to the sun being at its peak.
Leap second drift is super slow, too -- IIRC something like 10 minutes per millennium. If we shift our clocks by an hour in the year 8000 I think that's less disruptive than leap seconds every year or so.
Leap second drift is super slow, too -- IIRC something like 10 minutes per millennium. If we shift our clocks by an hour in the year 8000 I think that's less disruptive than leap seconds every year or so.
GPS time is no use for far in the future (TAI is OK).
Imagine someone 2,000 years in the future, discovering an archive containing exact GPS timestamps for events. There is no reason to suppose that our present GPS system will still exist - so these timestamps won't be much use to them, since they won't know what the present time (their present) is in terms of GPS. The timestamps in the archive will no longer be precise, as far as they're concerned.
Imagine someone 2,000 years in the future, discovering an archive containing exact GPS timestamps for events. There is no reason to suppose that our present GPS system will still exist - so these timestamps won't be much use to them, since they won't know what the present time (their present) is in terms of GPS. The timestamps in the archive will no longer be precise, as far as they're concerned.
As others pointed out:
1. because we want monotonously increasing time on our computer systems.
2. because software deals with leap anything very badly
3. [not mentioned]: we are in danger of running into negative leap seconds very soon: https://twitter.com/ariadneconill/status/1422163289518313474
1. because we want monotonously increasing time on our computer systems.
2. because software deals with leap anything very badly
3. [not mentioned]: we are in danger of running into negative leap seconds very soon: https://twitter.com/ariadneconill/status/1422163289518313474
What I've seen with embedded systems is you have a real time clock. And the system when it updates the time updates the registers in the real time clock. And then bad things always happen sooner or later
I've always just let the thing run and use an offset to calculate 'users local time'. If the time gets updated I update the offset.
I think that's what programmers want[1]. Instead of the current system system where the primary time unpredictably jumps around.
[1] For time of day programmers probably want a standard formula that takes an offset and a rate to output the time of day.
I've always just let the thing run and use an offset to calculate 'users local time'. If the time gets updated I update the offset.
I think that's what programmers want[1]. Instead of the current system system where the primary time unpredictably jumps around.
[1] For time of day programmers probably want a standard formula that takes an offset and a rate to output the time of day.
Interestingly, you can accommodate negative leap seconds with smears as well. FTA:
>> A negative leap second, if one were ever to occur, would be smeared by speeding up clocks over the 86,399 SI seconds from noon to noon.
>> A negative leap second, if one were ever to occur, would be smeared by speeding up clocks over the 86,399 SI seconds from noon to noon.
The shortest possible TL;DR of https://en.wikipedia.org/wiki/Leap_second#History appears to be "because TV and radio broadcast systems in the 1950s were based on solar time rather than astronomical time and wanted to stay in sync to each other."
There seems to have been a movement against leap seconds: https://en.wikipedia.org/wiki/Leap_second#International_prop...
There seems to have been a movement against leap seconds: https://en.wikipedia.org/wiki/Leap_second#International_prop...
Among other reasons (and in line with why Google cares to keep things tied to astronomical time measurments instead of perfect-period atomic clock measurements): if a user schedules something to happen at 'noon every day', they become dissatisfied if the timing of the event begins to drift off of "sun overhead" time consistently because of leap seconds.
Sun overhead time drifts around throughout the year anyway, a couple of seconds is much less of a difference than the difference due to seasons and much less than DST.
For example, solar noon is 1:15pm today in Seattle, and will be 1:09pm at the end of the month. Way more variability than the accumulated leap seconds over a century.
For example, solar noon is 1:15pm today in Seattle, and will be 1:09pm at the end of the month. Way more variability than the accumulated leap seconds over a century.
There are very few times and places on earth where the sun is directly overhead at noon. For example, solar noon is at a different time depending on where within a time zone you live, as well as the time of year.
Where within a city even. Solar noon in london varies by over two minutes depending which end of the district line you are - that’s 5 times the error “corrected” by leap seconds over the last 50 years.
Google always seems to want to fix symptoms while ignoring problems.
Or, from a different perspective, Google chooses to build a robust system that can paper over defects because human error is common, hard to test, & hard to detect when it comes to time AND the consequence of errors is a massive company wide outage.
I'm not a programmer, but I understand enough about systems administration to know why monotonic time is important.
But leap seconds exist for a reason - the rate of Earth's spin is not constant, so since the invention of clocks accurate enough to be able to tell that, we have had to invent a way of compensating for the variable rate of spin such that "midday" is still the middle of the day and "midnight" is still the middle of the night. Without adjustment, these concepts would slowly drift.
It makes me angry that programmers feel that they "own" the concept of time measurement enough to propose the abolition of leap seconds. The definition of unix time excluding leap seconds is really the origin of this nonsense, and it has always seemed to me that the obvious solution is computers should simply measure seconds since the epoch. Wikipedia describes this version as the "TAI-based variant" of Unix Time, and if we all used it, computers wouldn't even have to care about leap seconds, and conversion to standard time display could be done in userland, accounting for leap seconds in the process.
Civil time is more important than keeping your log files in order. Get your computers to count seconds, and leave more important human concepts like midday and midnight to the humans who are affected by them.