(Nor does Arrow. Maya doesn't really seem to support arithmetic on a MayaDT short of converting to a datetime, so in that regard, it behaves like Python.) The above output is not terribly surprising, as Python and a lot of software tend to follow Unix/POSIX time. Whether it is "right" depends.
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.
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.
Python does not do this:
(Nor does Arrow. Maya doesn't really seem to support arithmetic on a MayaDT short of converting to a datetime, so in that regard, it behaves like Python.) The above output is not terribly surprising, as Python and a lot of software tend to follow Unix/POSIX time. Whether it is "right" depends.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