I think if we all stipulate that some form of "display UTC" is the only representation that should be stored or forwarded,
You expect high-volume logging tools and network servers to convert every timestamp to year-month-day-hour-minute-second-subsecond?
I only expect entities that wish to exchange timestamps with other entities to convert them to a "display UTC" equivalent representation, which does not imply such a full breakdown. It is up to the protocol designer to choose the "display UTC" representation, and it is up to the local system to choose the timestamp representation. Both parties will undoubtedly want to make choices that simplify any conversions. [It would also be possible for the protocol to negotiate a mutually acceptable representation to avoid any conversions, but everyone should accept the "display UTC" equivalent.]
What exactly is the benefit of these conversions?
The benefit is the separation of local and remote representations. Might I liken it to exchanging floating point values?
you're kidding yourself if you expect UNIX filesystems to start storing inode times in that format.
I only expect them to store something equivalent to "display UTC". [POSIX time_t's fail to represent leap seconds. People seem to dislike struct xtime because of the ability to represent bogus leap seconds. TAI requires a leap-second table.] So choose any flavour you like locally, but don't force that choice upon those you communicate with. And recognize your shortcomings (for example, POSIX-time_t based file systems screw up file time orderings during leap seconds).
Bradley White writes:
TAI requires a leap-second table.
Nonsense. It is true that CONVERTING between civil times and numeric TAI64 times requires knowledge of leap seconds, the calendar, time zones, etc. However, the definition of TAI64 is much simpler than that. It doesn't involve leap seconds in any way. In contrast, you can't even tell which civil times are valid if you don't have a leap-second table.
What exactly is the benefit of these conversions? The benefit is the separation of local and remote representations.
TAI64 is not ``local'' by any sane definition. In fact, TAI64 was explicitly designed as a portable timestamp interchange format. See http://pobox.com/~djb/proto/tai64.txt. ---Dan 1000 recipients, 28.8 modem, 10 seconds. http://pobox.com/~djb/qmail/mini.html
Bradley White wrote on 1998-10-10 18:53 UTC: [very good discussion deleted, a agree with all you said]
People seem to dislike struct xtime because of the ability to represent bogus leap seconds.
Just for the record: ISO 8601 style display UTC as well as struct tm also has the ability to represent bogus leap seconds such as 01:02:60.123. Therefore I have serious problems understanding why exactly some people here feel uncomfortable about struct xtime because of this. (For the same reason, I also do not understand Paul's discomfort with the possibility of out-of-range nsec values.) Markus -- Markus G. Kuhn, Security Group, Computer Lab, Cambridge University, UK email: mkuhn at acm.org, home page: <http://www.cl.cam.ac.uk/~mgk25/>
Markus Kuhn wrote:
Bradley White wrote on 1998-10-10 18:53 UTC:
People seem to dislike struct xtime because of the ability to represent bogus leap seconds.
Just for the record: ISO 8601 style display UTC as well as struct tm also has the ability to represent bogus leap seconds such as 01:02:60.123.
But they do not give it any sense (except on input for mktime()). Also just for the record: 2000-06-30 23:59:60,456Z is a wrong timestamp these days, but it might very well be a correct one in 16 months from now (assuming the Earth's rotation variation does not change too much until that time). Same for the equivalent TIME_UTC value using struct xtime. But as noted by Bradley and David before, this is not a problem when you are only talking about inode times. Antoine
participants (4)
-
Antoine Leca -
Bradley White -
D. J. Bernstein -
Markus Kuhn