This is designed for programmers of user facing applications. For science and engineering, it does not address the problems, eg lack of leap seconds.
What do you mean by "lack of leap seconds"? A non-unix-timestamp-based time library?
As my co-worker once put it, "time is a four letter word."
At the very least, there is a need for showing the occasional 61st second of a minute, and adding a time and timedelta where leap seconds is taken into account.
I still don't understand what you mean.
> You could use time_t underneath, if that's what you really wanted to do.
Well you've got unix timestamp (UTC) which "skips" leap seconds but as a result is very easy to map to "human time", or you've got TAI[0] which includes leap seconds but doesn't allow dates in the future since you don't know where and when new leap seconds will be added long in advance, and now you need regular updates/permanent connectivity so you can remap TAI onto human time. And you need an NTP replacement, though I guess having a GPS unit in everything would do.
[0] and GPS time which is just TAI + 19s
2016-12-31T23:59:30Z + 60s == 2017-01-01T23:59:29Z
Python does not do this:
In [5]: datetime.datetime(2016, 12, 31, 23, 59, 30, tzinfo=pytz.UTC) + datetime.timedelta(seconds=60)
Out[5]: datetime.datetime(2017, 1, 1, 0, 0, 30, tzinfo=<UTC>)
You also mix up the various timescales:
> Well you've got unix timestamp (UTC) which "skips" leap seconds
Unix/POSIX time might not skip leap seconds; some will repeat a second as the leap second occurs. (I.e., while UTC counts 23:59:59, 23:59:60, 00:00:00, POSIX will count 23:59:59, 23:59:59, 00:00:00.) Linux falls into this latter case, I believe, during which time adjtimex() will return TIME_OOP.
However, Unix/POSIX time is not UTC. UTC never "skips" leap seconds, as leap seconds are an inherent property of UTC.
> or you've got TAI which includes leap seconds
TAI does not include leap seconds[1]:
> the name International Atomic Time (TAI) was assigned to a time scale based on SI seconds with no leap seconds.
> TAI is exactly 36 seconds ahead of UTC. The 36 seconds results from the initial difference of 10 seconds at the start of 1972, plus 26 leap seconds in UTC since 1972.
UTC: has leap seconds as a property of how it works
TAI: does not include leap seconds
POSIX/Unix time: an integer that can be mapped to UTC except during leap seconds, where it becomes ugly (unless you know if TIME_OOP was set, in which case it can still be mapped to UTC).
> but [TAI] doesn't allow dates in the future since you don't know where and when new leap seconds will be added long in advance, and now you need regular updates/permanent connectivity so you can remap TAI onto human time
With the above, it should be obvious that this is a property of UTC, not TAI. TAI timestamps in the future should be stable/usablable without surprises. UTC's might not be due to leap seconds.
[1]: https://en.wikipedia.org/wiki/International_Atomic_Time
No, but I think we're interpreting the word "skipping" differently which leads to confusion. To me, in TAI, a "leap second" is nothing special and included in the normal time stream, in UTC the leap second is removed from the normal time stream and tacked on as a special case on some specific days, hence skipping it, hence UTC running late compared to TAI: UTC has "removed" 36 seconds from the timestream compared to UTC.
> Unix/POSIX time might not skip leap seconds
UNIX/POSIX can only ignore leap seconds, how it does so doesn't matter, because it's defined as constant-length days, the timestamp is 86400days since epoch + seconds since midnight. The day after a leap second, that leap second has "disappeared" from the timestamp sequence.
> However, Unix/POSIX time is not UTC.
Unix time is specifically defined as UTC (at least after January 1st 1972 since that's when UTC was defined, pre-72 it's ambiguous), though not true since it can't represent* leap seconds. Outside of the extent of leap seconds, UNIX time tracks UTC exactly.
> as leap seconds are an inherent property of UTC.
They're an inherent property of UTC in that it removes them from normal time treatment.
> TAI does not include leap seconds[1]:
It includes them in the sense that it treats them as perfectly normal seconds without anything special about them.
> With the above, it should be obvious that this is a property of UTC, not TAI.
The paragraph you're quoting here (and my entire comment really) is talking about how these systems map to human time aka year/month/day/hour/minutes/seconds. Leap seconds were introduced specifically for that purpose, and UTC (and unix timestamps) are thus trivially mappable by definition.
Because it does not, TAI can't be mapped to human time without leap seconds definition AKA May 7th, 2078 at 17:54:33 is known in UTC, but not known in TAI, because we don't know how many leap seconds will be introduced in the next 61 years and that's necessary to map TAI to and from human time.
I have packets read from an instrument which are timestamped in seconds since 1980-01-06 (GPS Epoch). To compute each packet's proper datetime representation in TAI, I need add those seconds to 1980-01-06, and subtract the amount of leap seconds that occurred. The subtracting of leap seconds could be done automatically by a library. When a leap second is added, it will occur on the 61st second of the minute (second = :60). These times aren't supported by the datetime class.