Seeds, Glen
Wed, 02 Jul 2003 12:45:39 -0700
-----Original Message-----
> From: Steve Allen [mailto:[EMAIL PROTECTED]]
> Sent: July 2, 2003 12:50 PM
> To: [EMAIL PROTECTED]
> Subject: [LEAPSECS] making leap hours workable
> ...
> Unlike the POSIX timestamping community which has buried its head
> in the sand and refused to admit that time_t should be TAI, any
> form of TI must be uniformly incrementing forever.
There are several inaccuracies in this statement.
The POSIX timestamping community has already had many long discussions of these issues. The current state of the standard reflects several realities.
The first reality is that POSIX implementors and application writers, who are the only targets audiences of the POSIX standards, have no control over whether time_t is TAI, UTC, or anything else. This is under the control of the system owners and operators, and the host environment that the POSIX implementation is embedded in.
The second reality is that many existing applications depend on calculations that assume that time_t has exactly 86400 seconds per year. (Note that it does NOT follow from this that there are 86400 POSIX seconds in any given calendar year. It does follow that if there are more than that, the remainder are hard to represent in POSIX.)
The third reality is that almost all POSIX systems require a time representation that is easily relatable to local time. UTC+TZ is the only readily available precise measure of local time, so mandating TAI would conflict with this. (For this reason, the bias is the POSIX world is heavily toward UTC rather than TAI, and is behind much of the resistance to dropping leap seconds from UTC)
POSIX Real Time does recognize and mandate that there must be a monotonically increasing clock. It cannot and does not mandate that ALL sources of time_t are monotonic.
There has been discussion in this forum of "smoothed" leap seconds. Much of this was born of discussions within the POSIX community some years ago, and many existing implementations provide for smoothed time adjustment that guarantees a non-decreasing clock.
/glen
...
This message may contain privileged and/or confidential information. If you have received this e-mail in error or are not the intended recipient, you may not use, copy, disseminate or distribute it; do not open any attachments, delete it immediately from your system and notify the sender promptly by e-mail that you have done so. Thank you.
Join us at Cognos' biggest event of the year Enterprise 2003, The Cognos Business Forum. Taking place in over 25 cities around the world, it's an opportunity for Business and IT leaders to learn about strategies for driving performance. Visit www.cognos.com/enterprise03 for more details.