Paul Eggert wrote:
strfxtime and the other primitives currently return garbage unless you pass them a TIME_UTC timestamp. I suppose one could argue that they return well-defined garbage; but this well-defined garbage is useless for practical applications.
How about encoding the time type in the struct xtime itself? That permits safe error checking and the use of mixed time types particularly UTC vs. local in contexts like logs -- some devices that need to make log entries may not know the UTC time, only some random local time.
Suppose implementation X internally uses a clock with TAI seconds, but it doesn't know the TAI epoch;
Are not TAI seconds precisely the same as UTC seconds? TAI minutes, hours, days, months, years are different, but not seconds, IIRC: 1 TAI second = 1 UTC second = 9,192,631,770 cesium vibrations.
that is, it knows the leap second or seconds within a window of a few months around the current time, and it knows the relationship between its internal clock and UTC within this window, but it doesn't know all the leap seconds back to 1972.
I think that a more likely state is that it knows the earlier leap seconds between Now and 1972, but is missing some number (potentially zero) of the later ones. This corresponds to an un-updated leap second table.
This seems backwards to me; fundamentally, the implementation is based on TAI not UTC, and it should have some way to report this to the application.
What does it mean to be "based on TAI" at the second level?
If you combine solutions (2) and (3), then you don't need the current TIME_UTC any more. It's enough to have the generalization of TIME_TAI with implementation-defined epoch, along with the variant of TIME_UTC that never reports leap seconds.
A TIME_UTC that doesn't report leap seconds is not UTC at all, but TAI-10. Its minutes are always exactly 60 sec long. -- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)