RE: [LEAPSECS] making leap hours workable

From: Seeds, Glen <Glen.Seeds_at_COGNOS.COM>
Date: Thu, 3 Jul 2003 17:18:26 -0400

> -----Original Message-----
> From: ut1-mail_at_ASTHE.COM [mailto:ut1-mail_at_ASTHE.COM]
> Sent: July 2, 2003 4:32 PM
> To: LEAPSECS_at_ROM.USNO.NAVY.MIL
> Subject: Re: [LEAPSECS] making leap hours workable
>
>
> > 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. ...
>
> Obviously you mean "per day".
Yes - sorry for the typo.

>
> > UTC+TZ is the only
> > readily available precise measure of local time, so
> mandating TAI would
> > conflict with this.
>
> I beg to differ on your use of "precise measure". Nothing in
> POSIX requires
> time (local, time_t, etc.) to be precise.

I don't disagree. However, there are some POSIX users with such a
requirement.

>
> Correct me if I am wrong, but:
>
> Timezones in POSIX are defined as offsets of the "UTC timezone"
> (sic) as P1003.1 once called it. Names of points in time
> within the "UTC
> timezone" are computed from those "seconds since the
> Epoch" timestamp /
> time_t values.
>
> Nothing in POSIX, as far as I can see, says that
> "PST8PDT" has anything
> to do with UTC, local standard time, TAI, etc. It is a 8
> hour offset
> from that "UTC timezone" which related to those "seconds
> since the Epoch"
> timestamp values / time_t values. And as you point out:
>
> > POSIX implementors and application writers ... 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 time_t can be anything ... including TAI, UTC, a
> bogus clock, etc.
>
> * So time_t can be related to almost anything.
>
> * The POSIX "TZ=UTC" names computed from those seconds
> since the Epoch"
> time_t timestamp values can therefore related to almost
> anything.
>
> * Timezones such as "PST8PDT" are 8 hours off of POSIX "TZ=UTC",
> can therefore related to almost anything.
>
> And thus the claim of "mandating TAI would conflict with this" appears
> to be false.
>
> =-=
>
> I am not commenting on the value/wisdom of "mandating TAI". But from
> my reading of POSIX, it appears that there is no POSIX conflict in
> "mandating TAI".
>
> chongo () /\oo/\
>
> =-=
>
>

Yes and no. This is a slippery area, as we all know. Here's the exact
wording (from the most recent published version of POSIX's current
incarnation - the Single UNIX Specification:
"
The expanded format (for all TZs whose value does not have a colon as the
first character) is as follows:
        stdoffset[dst[offset][,start[/time],end[/time]]]
...
offset Indicates the value added to the local time to arrive at
        Coordinated Universal Time. The offset has the form:
        hh[:mm[:ss]]
"

It's clear from this wording that the INTENT her is for time base to
actually be UTC. How well that intent maps to reality is (as already
mentioned), not under direct POSIX control. However, deliberate use of TAI
as a base, rather than UTC, would clearly violate this intent.

  /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 Thu Jul 03 2003 - 14:19:16 PDT