[ntp:questions] Google and leap seconds
stenn at ntp.org
Wed Sep 21 22:04:18 UTC 2011
> Once upon a time, unruh <unruh at wormhole.physics.ubc.ca> said:
>> Posix clearly has never even though about leapseconds, so their
>> recommendations are pretty irrelevant.
> I wouldn't say they never thought about them; they made a choice to
> avoid them because too much code assumes "(time()%86400)==0" means
> midnight UTC, and leap seconds break that (making basic clock handling
> much more complicated).
And once upon a time folks took liberties with calendar code, because
leap-year handling was "more work". This was in the days when the
internet was young and it took more effort to reasearch the correct
algorithms, and then you had to code and test them properly.
We're beyond *that* hurdle now...
What about the discussions around the creation of difftime()? Folks
used to like to dream about using simpler solutions there, too.
I think it would be worth exploring some library functions to handle
leapseconds in interval calculations and presentation.
But I fully expect that folks will take the "easy" way out on this,
as the pain/cost of a "better" solution is, frankly, not presently worth
> At least on Linux, you can choose to have leap seconds, based on the
> $ TZ=UTC date -d @1230768023
> Thu Jan 1 00:00:23 UTC 2009
> $ TZ=right/UTC date -d @1230768023
> Wed Dec 31 23:59:60 UTC 2008
> but that is just done in the timezone conversion, not the actual clock
because the timescales are different. The timescale is a necessary part
of the metadata.
I think this overall situation is a case where "implied metadata" is
Not surprising - there are costs in making the metadata explicit, and
the status-quo is fine until it is not...
In theory, practice and theory are the same. But in practice, they are not.
More information about the questions