Re: What does POSIX say? (was Re: What TZ do you use to get right time w/ clockspeed?)

Bennett Todd <[email protected]> wrote:
> Greg Woods on the Postfix list surprised me with the assertion,
> which I don't care to debate, that there aren't any practical POSIX
> implementations out there;

Uh...

> that what POSIX actually calls for is to keep the clock anchored to
> the original epoch, but fail to advance it for leap seconds,

That's how I read POSIX, and that's how implementations behave (more
or less; I imagine many actual clocks advance and then jump
backwards).  So I wonder how he arrives at the idea that there are no
practical implementations.

(You mentioned a "moving epoch" earlier.  That actually doesn't
describe the POSIX clock very well.  If the epoch really moved for a
leap second, that would affect the interpretation of *all* time_t
values, not just the ones after the leap second.  A better description
would be that each range of time between a pair of leap seconds has
its own epoch; each such epoch is itself fixed, but distinct from the
epochs used for time ranges between other pairs of leap seconds.)

> producing a sort of reverse bias, where the clock requires
> the opposite correction from a TAI clock for leap seconds.

Eh, sort of.  With a TAI clock, everyone can happily ignore leap
seconds while doing "t1-t0"-style interval calculations, but libraries
must account for leap seconds when converting to/from broken-down
human-comprehensible formats (e.g., by subtracting the appropriate
number of leap seconds from the time_t value, and then breaking down
the result as if it were POSIX).  With a POSIX clock, everyone has to
account for leap seconds when doing interval calculations (e.g., by
adding or removing a second to the interval if the two times occurred
on different sides of a leap second), but libraries can happily ignore
them when converting.


paul