3 ms·

This is designed for programmers of user facing applications. For science and engineering, it does not address the problems, eg lack of leap seconds.

cgvgffyv 10y ago
You need to wait for another rewrite with a cute name for these.
masklinn 10y ago
> 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?
- meltingwax 10y ago
  When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. You could use time_t underneath, if that's what you really wanted to do. 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.
  - masklinn 10y ago
    > 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
    - deathanatos 10y ago
      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 https://en.wikipedia.org/wiki/International_Atomic_Time
      - meltingwax 10y ago
        Thanks for clarifying my statement!
bpicolo 10y ago
Seems like your OS / clock source should always be the guy handling leap seconds. Why would a higher-level library do it? The cases are pretty rare that you'd want to think differently about leap seconds in higher level code.
- meltingwax 10y ago
  Here's an example: 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.

cgvgffyv 10y ago

You need to wait for another rewrite with a cute name for these.

masklinn 10y ago

> 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?

meltingwax 10y ago
When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. You could use time_t underneath, if that's what you really wanted to do. 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.
- masklinn 10y ago
  > 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
  - deathanatos 10y ago
    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 https://en.wikipedia.org/wiki/International_Atomic_Time
    - meltingwax 10y ago
      Thanks for clarifying my statement!

bpicolo 10y ago

Seems like your OS / clock source should always be the guy handling leap seconds. Why would a higher-level library do it? The cases are pretty rare that you'd want to think differently about leap seconds in higher level code.

meltingwax 10y ago
Here's an example: 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.