kkenny2 at nycap.rr.com
Thu Jun 30 13:15:20 UTC 2011
I'm going to tak a contrarian view -- at least from the perspective
of the group here -- and assert that the Posix committee got it nearly
right. (Or at least that the damage was done before the standardisation
effort got under way.)
Posix time, unfortunately, has served a dual purpose. It is used for
measuring intervals - but it is also civil time: "what time is it on
the clock on the wall?" And it has been used - from the very earliest
days - as a calculation device for the civil clock. I would venture
the guess that virtually all programs that depend on "seconds from
1 January 1970" actually are doing things like computing days between
two times:" (time1/86400 - time2/86400). Programmers who do things
ranging from financial applications to television schedules want this
Eventually, those who do television schedules realize
that they have to deal also with leap seconds and drop frames. But
that sort of thing winds up being left to specialists: the people who
code the business applications of television don't care about those
details, don't want to care, and shouldn't have to care. Even the
technical directors and videotape editors are usually ignorant of the
details: "some seconds have only 29 frames. It's like leap year" is
the usual level of understanding.
And having an integer representation of civil time, that well-defined
calendar algorithms can handle without auxiliary tables that need to
be updated, is too great a convenience to pass up lightly.
So: Make the TAI clock separate from the UTC clock. Synchronize the
two, either using something like adjtimex() that makes the change
almost imperceptible, or by making the change rare enough that it
can be a planned-for event (the 'leap hour' proposal). I don't really
care which. (The code that I've written does the first, because that's
the best compromise available with today's standards.) But don't
take away an integer "UTC clock" merely because it ticks irregularly.
The irregular ticks are useful for the vast majority of people to
whom leap seconds are an academic curiosity.
Define a new set of APIs for dealing with TAI. If that's too much work,
bite the bullet and accept leap hours. We won't need one in the
lifetime of the prospective lifetime of the great-grandchildren of
those in the cradle today. That may be kicking the can down the road,
but it's a very long kick.
73 de ke9tv/2, Kevin
More information about the tz