Steve Summit <[email protected]> wrote:
>
> I think about Posix time_t in three ways:
>
> 1. It's utterly broken, in that it claims to be UTC, but fails to
> handle the one facet that distinguishes UTC from other timescales.
(It's actually UT(unspecified) but it's in denial)
> 2. It's wildly useful, because it's perfectly continuous, and
> allows you to seamlessly integrate clock and calendar handling
> at the second, day, and year scales.
>
> 3. Its definition can't be changed, because its published
> definition absolutely allows (and even encourages) any random
> scrap of user code out there to use its own handcrafted logic
> to convert back and forth between time_t and calendar time,
> meaning that we can't just "fix" the Posix leap-second problem
> by redefining time_t and then rewriting library functions like
> localtime() to use our new, improved definition. Posix time_t
> is here to stay.
3a. It is baked into many file formats, disk formats and protocols.
These are much harder to fix than the APIs. (You mentioned this
later in your message, but it's a common error to focus on the API
problem to the exclusion of the data problem.)
Tony.
--
f.anthony.n.finch <[email protected]> http://dotat.at/ - I xn--zr8h punycode
Thames, Dover, Wight, Portland, Plymouth: West or southwest, veering northwest
later, 3 or 4, increasing 5 at times. Smooth or slight, occasionally moderate
in Plymouth. Drizzle and fog patches at first in Thames and Dover. Moderate or
good, occasionally very poor at first in Thames and Dover.
_______________________________________________
LEAPSECS mailing list
[email protected]
https://pairlist6.pair.net/mailman/listinfo/leapsecs
