What I believe he's trying to say is that sometimes, you need a library capable of the following:
2016-12-31T23:59:30Z + 60s == 2017-01-01T23:59:29Z
(The above is a true statement, due to the presence of a leap second in the duration.)
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>)
(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
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