FW: Definition of time_t changed from signed to unsigned...

Susan Richards is not on the time zone mailing list; direct replies appropriately. --ado -----Original Message----- From: Susan Richards [mailto:cj_richards@hotmail.com] Sent: Wednesday, August 18, 2004 12:58 PM To: clive@demon.net; guy@alum.mit.edu Cc: tz@lecserver.nci.nih.gov Subject: Re: Definition of time_t changed from signed to unsigned... Hello All, I have another (potentially stupid) question regarding the interaction of NTP, leap seconds and the timezone database: As I've been going through the TZ code, I've seen the leap correction code. It appears that the adjustment for leap seconds is made when converting the UTC system time (which includes leap seconds) to POSIX (which does not) or visa versa. So my understanding is:- UTC - includes leap seconds POSIX - no leap seconds included. Is this correct? If my system is maintaining UTC (as set by some NTP server), and running the timezone database code, then are my following assumptions correct: 1) The result of calling time(0) is UTC (as maintained by NTP) and does include leap seconds. 2) The date & time displayed using "date" also takes into account leap seconds. 3) If I want to report POSIX time, I need to call time2posix(). Thanks for your time. Chris. From: "Clive D.W. Feather" <clive@demon.net> To: Guy Harris <guy@alum.mit.edu> CC: Chris Richards <cj_richards@hotmail.com>, Tz <tz@lecserver.nci.nih.gov> Subject: Re: Definition of time_t changed from signed to unsigned... Date: Tue, 20 Jul 2004 09:30:31 +0100 Guy Harris said: >>> If you can, I'd change the time_t typedef in the OS. >> Changing an OS-supplied definition is EXTREMELY DUMB. You're risking >> breaking the OS interfaces. > When he said "I am in the process of upgrading the kernel version on a > platform that I > work on.", it sounded as if he might be one of the developers *of* that > platform In which case it's a very different kettle of fish, I agree. I read the original thread as suggesting just changing the header file available to user code and reacted accordingly - that remains extremely dumb. Changing the OS's own definitions is, of course, completely different. If I've reacted over nothing, I apologise to all concerned. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | | _________________________________________________________________ Is your PC infected? Get a FREE online computer virus scan from McAfee(r) Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

From: Susan Richards [mailto:cj_richards@hotmail.com] Sent: Wednesday, August 18, 2004 12:58 PM
It appears that the adjustment for leap seconds is made when converting the UTC system time (which includes leap seconds) to POSIX (which does not) or visa versa.
So my understanding is:- UTC - includes leap seconds POSIX - no leap seconds included.
Is this correct?
Not really, though the issue is not as clear as it should be. When you're talking about time as a count of seconds since an epoch, POSIX time omits completed leap seconds. UTC is normally thought of as a broken-down time like "1998-12-31 23:59:60" (the last leap second), but if you want to think of it as a count of seconds, then it's equivalent to POSIX time. See, for example, the official announcement of the latest leap second: <http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.16> This announcement makes it clear that UTC-TAI was -31 seconds through the last leap second, and -32 seconds thereafter, and this is exactly how POSIX time behaves. So it would be more accurate for you to write: TAI - includes leap seconds POSIX - no leap seconds included
If my system is maintaining UTC (as set by some NTP server), and running the timezone database code, then are my following assumptions correct:
1) The result of calling time(0) is UTC (as maintained by NTP) and does include leap seconds.
Typically NTP maintains POSIX time, not TAI. I don't know if you can configure it to maintain TAI.
2) The date & time displayed using "date" also takes into account leap seconds.
If you've configured your system so that time_t counts TAI seconds instead of POSIX/UTC seconds, and if you're using the Olson code with a "right" database, then yes, the date & time code does that.
3) If I want to report POSIX time, I need to call time2posix().
Yes, that sounds right.

Paul Eggert scripsit:
When you're talking about time as a count of seconds since an epoch, POSIX time omits completed leap seconds. UTC is normally thought of as a broken-down time like "1998-12-31 23:59:60" (the last leap second), but if you want to think of it as a count of seconds, then it's equivalent to POSIX time.
How can that be? A count of UTC seconds since the Epoch is the same as a count of TAI seconds, since 1 UTC second always equals 1 TAI second of elapsed time. It's only when we convert from a count of seconds to broken-out time that we see a difference between TAI and UTC.
This announcement makes it clear that UTC-TAI was -31 seconds through the last leap second, and -32 seconds thereafter, and this is exactly how POSIX time behaves.
POSIX time counts the number of non-leap seconds since the Epoch, but the seconds themselves are 1 TAI second = 1 UTC second = 1 SI second in length. -- One Word to write them all, John Cowan <jcowan@reutershealth.com> One Access to find them, http://www.reutershealth.com One Excel to count them all, http://www.ccil.org/~cowan And thus to Windows bind them. --Mike Champion

John Cowan <jcowan@reutershealth.com> writes:
A count of UTC seconds since the Epoch is the same as a count of TAI seconds
Only if you are talking about broken-down labels for time. But I was talking about time expressed as a count of seconds. For example, the two adjacent real-time seconds with broken-down labels 1998-12-31 23:59:60 and 1999-01-01 00:00:00 UTC have the same count-of-seconds since the epoch. This is according to the official definition of UTC. Here's an example of the official wording: The difference between UTC and the International Atomic Time TAI is: from 1997 July 1, 0h UTC, to 1999 January 1, 0h UTC : UTC-TAI = - 31s from 1999 January 1, 0h UTC, until further notice : UTC-TAI = - 32s This is a quote from IERS Bulletin C 16 (1998-07-17) <http://hpiers.obspm.fr/eoppc/bul/bulc/bulletinc.16>. Since TAI ticks along uniformly, and UTC-TAI jumps backwards by 1 second at the end of the inserted leap second, it logically follows that UTC also jumps backward by 1 second at the same moment.
POSIX time counts the number of non-leap seconds since the Epoch
Yes. More precisely, POSIX time is defined by the following C-language expression, for years>=1970 (i.e., tm_year >= 70): tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400 + (tm_year-70)*31536000 + ((tm_year-69)/4)*86400 - ((tm_year-1)/100)*86400 + ((tm_year+299)/400)*86400 Reference: <http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap04.html#tag_0...> This equation says that the POSIX clock hops backward by 1 second immediately after an inserted leap second (i.e., a second where tm_sec == 60). This is consistent with the official definition of UTC quoted above.

Paul Eggert scripsit:
A count of UTC seconds since the Epoch is the same as a count of TAI seconds
Only if you are talking about broken-down labels for time. But I was talking about time expressed as a count of seconds. For example, the two adjacent real-time seconds with broken-down labels 1998-12-31 23:59:60 and 1999-01-01 00:00:00 UTC have the same count-of-seconds since the epoch.
No, I don't believe so. The two adjacent seconds you mention have the same _Posix_ time, but the number of elapsed UTC seconds = TAI seconds = SI seconds since the Epoch is not the same; ergo, on an Olsen-right system the values returned by gmtime will be different for these two labels.
Since TAI ticks along uniformly, and UTC-TAI jumps backwards by 1 second at the end of the inserted leap second, it logically follows that UTC also jumps backward by 1 second at the same moment.
Both TAI and UTC tick along uniformly at a rate of 1 SI second per second at all times (as opposed to other time scales which do not). It is simply that the broken-down time labels of UTC do something unusual at a leap second, whereas those of TAI do not. The statement that TAI-UTC changes applies to broken-down time labels, not to elapsed time. (I suspect that our disagreement is primarily or even entirely terminological.) -- "They tried to pierce your heart John Cowan with a Morgul-knife that remains in the http://www.ccil.org/~cowan wound. If they had succeeded, you would http://www.reutershealth.com become a wraith under the domination of the Dark Lord." --Gandalf

John Cowan said:
A count of UTC seconds since the Epoch is the same as a count of TAI seconds Only if you are talking about broken-down labels for time. But I was talking about time expressed as a count of seconds. For example, the two adjacent real-time seconds with broken-down labels 1998-12-31 23:59:60 and 1999-01-01 00:00:00 UTC have the same count-of-seconds since the epoch. No, I don't believe so. The two adjacent seconds you mention have the same _Posix_ time, but the number of elapsed UTC seconds = TAI seconds = SI seconds since the Epoch is not the same;
On the other hand, Paul is right to talk about UTC-TAI changing. Perhaps a way to think about it is that UTC has two kinds of seconds: normal and leap. number of TAI seconds = number of UTC normal seconds + leap seconds number of POSIX seconds = number of UTC normal seconds TAI broken down time is based on number of TAI seconds POSIX broken down time is based on number of POSIX seconds UTC broken down time is based on number of UTC normal seconds It's not really useful to talk about the number of UTC seconds elapsed, since the whole point of UTC is its broken-down form. The only useful thing is the number of normal seconds elapsed. So I suppose I'm with Paul, here. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |
participants (4)
-
Clive D.W. Feather
-
John Cowan
-
Olson, Arthur David (NIH/NCI)
-
Paul Eggert