Why? Why don’t we use TAI or GPS time for generic world wide coordinated computer time?
[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.
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.
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.
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... )
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.
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].
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.
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.
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
>> 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.
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.
There seems to have been a movement against leap seconds: https://en.wikipedia.org/wiki/Leap_second#International_prop...
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.