Re: making leap hours workable
Title: RE: [LEAPSECS] making leap hours workable I believe you would get very strong pushback from the POSIX world if you tried to make the time base TAI rather than UTC. Without a strong case for this change (which I haven't seen yet), I would be one of them. /glen -Original Message- From: Steve Allen [mailto:[EMAIL PROTECTED]] Sent: July 2, 2003 5:04 PM To: [EMAIL PROTECTED] Subject: Re: [LEAPSECS] making leap hours workable On Wed 2003-07-02T15:45:44 -0400, Seeds, Glen hath writ: From: Steve Allen [mailto:[EMAIL PROTECTED]] 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. I stand by the tense of my statement: time_t *should* be TAI in order that POSIX timestamps can be unambiguous and monotonically increasing. I fully recognize the realities that prevent it from being TAI. And I applaud the POSIX Real Time folks for taking the broader view which, when fully implemented, will permit compatibility with existing usage as well as monotonicity. The notion of DUTH in my proposal is the safety valve which permits leap seconds to be ignored for 500 years while still demanding that there be a mechanism which will handle the longer term problems. If such a DUTH scheme were implemented it might still be that posterity would decide never to increment it, but at least they would have the option built into the systems of the world. sign me Waiting (but not holding my breath) for the SRG to take the same sort of broader view with respect to civil time and broadcast time signals. -- Steve Allen UCO/Lick Observatory Santa Cruz, CA 95064 [EMAIL PROTECTED] Voice: +1 831 459 3046 http://www.ucolick.org/~sla PGP: 1024/E46978C5 F6 78 D1 10 62 94 8F 2E 49 89 0E FE 26 B4 14 93 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.
Re: making leap hours workable
Title: RE: [LEAPSECS] making leap hours workable -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: July 2, 2003 4:32 PM To: [EMAIL PROTECTED] 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.
Re: 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. 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. 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/\ =-= 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. And for my EMail disclaimer: My sending me EMail, you wave the right to dictate control over any privileged and/or confidential information contained in such EMail AND you grant me full authority to use such EMail in any way or method that is permitted by law. :-)
