RE: [LEAPSECS] making leap hours workable

From: Seeds, Glen <Glen.Seeds_at_COGNOS.COM>
Date: Wed, 2 Jul 2003 15:45:44 -0400

-----Original Message-----
> From: Steve Allen [mailto:sla_at_UCOLICK.ORG]
> Sent: July 2, 2003 12:50 PM
> To: LEAPSECS_at_ROM.USNO.NAVY.MIL
> 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.
Received on Wed Jul 02 2003 - 12:47:15 PDT