undefined | Better HN

0 pointsmasklinn9y ago0 comments

> When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds.

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

0 comments

3 comments · 1 top-level

deathanatos9y ago· 2 in thread

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

masklinnOP9y ago

> You also mix up the various timescales:

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.

meltingwax9y ago

Thanks for clarifying my statement!

j / k navigate · click thread line to collapse