xtime/libtai/"right"

[Bradley White]

>> 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).