4 ms·

UTC is not a representation or a display-format. That display-format appears to be (derived from?) ISO 8601. And I think ISO 8601 is not bound to UTC; it could

UTC is not a representation or a display-format. That display-format appears to be (derived from?) ISO 8601. And I think ISO 8601 is not bound to UTC; it could equally be used to represent Solar Time. Possibly the most natural representation of a UTC instant would be an integer, because fundamentally UTC is a count of milliseconds. Just quibbling about terminology! Not knocking the program, I like it.

38 3y ago
its RFC 3339
burntsushi 3y ago
> Possibly the most natural representation of a UTC instant would be an integer, because fundamentally UTC is a count of milliseconds It's not! It's a subtle point, but because of leap seconds, the correct representation of UTC is the tuple (year, month, day, hour, minute, second, ...), with the `...` being filled in with your desired precision. From: http://www.madore.org/~david/computers/unix-leap-seconds.html http://www.madore.org/~david/computers/unix-leap-seconds.htm... > Unlike TAI and UT1, the UTC time scale should not be considered as a pure real number (or seconds count): instead, it should be viewed as a broken-down time (year-month-day-hour-minute-second-fraction) in which the number of seconds ranges from 0 to 60 inclusive (there can be 61 or 59 seconds in a minute); during a positive leap second the number of seconds takes the value 60 (while a negative leap second would skip the value 59, but this has never occurred). ... > If we attempt to condense UTC to a single number (say, the number of seconds since 1970-01-01T00:00:00 or since 1900-01-01T00:00:00, or the number of 86400s-days since 1858-11-17T00:00:00, or something of the sort), we encounter the problem that the same value can refer to two different instants since the clock has been set back one second (negative leap seconds, of course, would cause no such difficulty). Most datetime libraries get this wrong. I know because I'm working on a new one that specifically doesn't get this wrong.
- erhaetherth 3y ago
  We could technically do # of minutes since 1970-01-01T00:00:00 (or whatever) & seconds though, no? (int32 minutes, double seconds) would get us a pretty big range in a pretty compact format.
  - burntsushi 3y ago
    There are lots of equivalent representations. The main point here is that it's misleading to think of UTC as just a timestamp from some epoch. It needs something richer than that.

38 3y ago

its RFC 3339

burntsushi 3y ago

> Possibly the most natural representation of a UTC instant would be an integer, because fundamentally UTC is a count of milliseconds It's not! It's a subtle point, but because of leap seconds, the correct representation of UTC is the tuple (year, month, day, hour, minute, second, ...), with the `...` being filled in with your desired precision. From: http://www.madore.org/~david/computers/unix-leap-seconds.html http://www.madore.org/~david/computers/unix-leap-seconds.htm... > Unlike TAI and UT1, the UTC time scale should not be considered as a pure real number (or seconds count): instead, it should be viewed as a broken-down time (year-month-day-hour-minute-second-fraction) in which the number of seconds ranges from 0 to 60 inclusive (there can be 61 or 59 seconds in a minute); during a positive leap second the number of seconds takes the value 60 (while a negative leap second would skip the value 59, but this has never occurred). ... > If we attempt to condense UTC to a single number (say, the number of seconds since 1970-01-01T00:00:00 or since 1900-01-01T00:00:00, or the number of 86400s-days since 1858-11-17T00:00:00, or something of the sort), we encounter the problem that the same value can refer to two different instants since the clock has been set back one second (negative leap seconds, of course, would cause no such difficulty). Most datetime libraries get this wrong. I know because I'm working on a new one that specifically doesn't get this wrong.

erhaetherth 3y ago
We could technically do # of minutes since 1970-01-01T00:00:00 (or whatever) & seconds though, no? (int32 minutes, double seconds) would get us a pretty big range in a pretty compact format.
- burntsushi 3y ago
  There are lots of equivalent representations. The main point here is that it's misleading to think of UTC as just a timestamp from some epoch. It needs something richer than that.