gmtime(): Doesn't account for leap seconds?!
Edward J Sabol
doesn't take leap seconds into account when converting from a time_t variable
to a tm structure. This is on the DEC OSF/1 3.2 machine I'm using for
development. Is this a platform-specific bug or is this function not required
by the ISO/ANSI standards to take leap seconds into account on any platform?
If it's the former, are there any Unix operating systems where gmtime() takes
leap seconds into account? If so, which ones?
And before I reinvent the wheel, does anyone have the source code to a
portable version of gmtime() that does in fact take leap seconds into
account?
Please respond by e-mail in addition to posting, if possible.
Thanks,
Ed
Jonathan Kamens
Second, in fact, paying attention to leap seconds is a violation of the POSIX
standard. That is, the POSIX definitions of the various time-related
functions ignore leap seconds, and any C library which pays attention to them
is in violation of the standards.
Third, the time function that are in the Linux libc deal with leap seconds,
and I'm sure they're free :-), so you can download the source code to them and
take a look to see if they originate there or if they're actually part of some
other package that is integrated into the Linux libc (I suspect the latter).
Lawrence Kirby
j...@annex-1-slip-jik.cam.ov.com "Jonathan Kamens" writes:
>First of all, gmtime() is governed by POSIX specs, not by ISO or ANSI specs.
ANSI C "7.12.3.3 The gmtime function"
POSIX defers to ANSI C for the definition of gmtime(). The tm_sec member
of a struct tm is permitted a range of 0 to 61 under ANSI C so leap
seconds are supported. However ANSI C doesn't define the representation of a
time_t value whereas POSIX, to a great extent, does. I don't know the
exact details but it would be that definition that prevents leap seconds
being supported.
>Second, in fact, paying attention to leap seconds is a violation of the POSIX
>standard. That is, the POSIX definitions of the various time-related
>functions ignore leap seconds, and any C library which pays attention to them
>is in violation of the standards.
>
>Third, the time function that are in the Linux libc deal with leap seconds,
>and I'm sure they're free :-), so you can download the source code to them and
>take a look to see if they originate there or if they're actually part of some
>other package that is integrated into the Linux libc (I suspect the latter).
LINUX is supposedly POSIX compliant. Then by your argument above its standard
library cannot support leap seconds at least not when used in a POSIX
conforming mode.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Jonathan Kamens
|> However ANSI C doesn't define the representation of a
|> time_t value whereas POSIX, to a great extent, does. I don't know the
|> exact details but it would be that definition that prevents leap seconds
|> being supported.
Yes, I believe that's where it occurs. I believe that it specifies the
algorithm by which a time_t value is converted to a date, and that algorithm
assumes that time_t 0 is 1/1/1970 00:00:00 GMT and that time increases in
sixty-second minutes from that point forward forever.
|> LINUX is supposedly POSIX compliant. Then by your argument above its standard
|> library cannot support leap seconds at least not when used in a POSIX
|> conforming mode.
LINUX isn't "POSIX-complaint", per se, since only one Linux distribution
(Linux-FT) has been tested for compliance, and that distribution made numerous
changes to standard Linux software in order to obtain compliance. It's
entirely possible that they ripped out the leap second support in order to
pass the POSIX tests. Or that they didn't try to obtain full POSIX
compliance, and therefore weren't tested in this particular way. Or that the
POSIX tests missed this one :-).
Also, a Linux system without a file recording leap seconds *will* handle time
in a POSIX-compliant way, since if no leap seconds are defined, time will
behave as POSIX requires. It's just that if some goes ahead and adds leap
seconds to the configuration of the system, it will no longer be
POSIX-complaint. Therefore, it wouldn't surprise me at all if Linux-FT passed
the compliance tests simply by not configuring leap seconds, but leaving the
funcionality in so that their users can configure them in (and thereby "break"
POSIX compliance) if they desire.
Chuck Karish
Jonathan Kamens <j...@annex-1-slip-jik.cam.ov.com> wrote:
>LINUX isn't "POSIX-complaint", per se, since only one Linux distribution
>(Linux-FT) has been tested for compliance, and that distribution made numerous
>changes to standard Linux software in order to obtain compliance. It's
>entirely possible that they ripped out the leap second support in order to
>pass the POSIX tests. Or that they didn't try to obtain full POSIX
>compliance, and therefore weren't tested in this particular way. Or that the
>POSIX tests missed this one :-).
A version of Linux has been certified to conform to FIPS 151-2. It's
not necessary to speculate about what might have been tested, because
the source code of the NIST POSIX test suite tells the story.
A system that corrects for leap seconds in gmtime() will definitely
fail the NIST test.
>Also, a Linux system without a file recording leap seconds *will* handle time
>in a POSIX-compliant way, since if no leap seconds are defined, time will
>behave as POSIX requires. It's just that if some goes ahead and adds leap
>seconds to the configuration of the system, it will no longer be
>POSIX-complaint. Therefore, it wouldn't surprise me at all if Linux-FT passed
>the compliance tests simply by not configuring leap seconds, but leaving the
>funcionality in so that their users can configure them in (and thereby "break"
>POSIX compliance) if they desire.
The right way to handle this is to provide a separate set of
functions for use in those programs where leap seconds make a
difference.
--
Chuck Karish kar...@mindcraft.com
(415) 323-9000 x117 kar...@pangea.stanford.edu
Chuck Karish
Jonathan Kamens <j...@annex-1-slip-jik.cam.ov.com> wrote:
>First of all, gmtime() is governed by POSIX specs, not by ISO or ANSI specs.
What's your point? ISO has standards for POSIX.1 (9945-1) and for
C (9989). The ISO C standard specifies the behavior of gmtime().
Chuck Karish
Lawrence Kirby <fr...@genesis.demon.co.uk> wrote:
>In article <4lid0q$i...@jik.israel.net>
> j...@annex-1-slip-jik.cam.ov.com "Jonathan Kamens" writes:
>
>
>
>POSIX defers to ANSI C for the definition of gmtime(). The tm_sec member
>of a struct tm is permitted a range of 0 to 61 under ANSI C so leap
>time_t value whereas POSIX, to a great extent, does. I don't know the
>exact details but it would be that definition that prevents leap seconds
>being supported.
The C Standard doesn't consider leap seconds at all. An implementation
can conform whether or not it handles leap seconds.
POSIX.1 says that time() returns the number of seconds since the
Epoch (4.5.1.2), and gives an algorithm relating the result to UCT that
ignores leap seconds (2.2.2.77). Use of this algorithm by the
time manipulation functions of the C Standard is mandated in 8.1.
P.Bennett
>
>What is the algorithm for leap seconds anyway? Are they used in years
>ending with 00, or only years divisible by 400?
There is no fixed schedule for leap seconds - they are inserted as needed, when
this wobbly old earth gets too far out of sync with the atomic clocks. (or vice
versa). There have been 11 since 1980, I believe (the last one was last Dec.
31.)
Peter Bennett VE7CEI | Vessels shall be deemed to be in sight
Internet: ben...@triumf.ca | of one another only when one can be
Packet: ve7cei@ve7kit.#vanc.bc.ca | observed visually from the other
TRIUMF, Vancouver, B.C., Canada | ColRegs 3(k)
GPS and NMEA info and programs: ftp://sundae.triumf.ca/pub/peter/index.html
or: ftp://ftp-i2.informatik.rwth-aachen.de/pub/arnd/GPS/peter/index.html
or: http:://vancouver-webpages.com/peter/index.html
Bill Marcum
What is the algorithm for leap seconds anyway? Are they used in years
ending with 00, or only years divisible by 400?
--
Bill Marcum bma...@iglou.com
"Even the samurais have teddy bears, and even the teddy bears get drunk"
(don't ask me what it means, it came from the 'fortune' program).
Jonathan Kamens
|> What is the algorithm for leap seconds anyway? Are they used in years
|> ending with 00, or only years divisible by 400?
There is no "algorithm". A leap second is inserted or removed when the body
which governs such things determines that it is necessary to do so in order to
bring our clocks into sync with the rotation of the Earth.
The Earth's rotation time isn't precisely constant. Leap seconds correct for
the variability.
The newsgroup where discussion of the mechanics of leap seconds is least
inappropriate (I'm not even sure it's appropriate there) is sci.astro, so I've
directed followups there.
Mark Brader
> POSIX.1 says that time() returns the number of seconds since the
> Epoch (4.5.1.2), and gives an algorithm relating the result to UCT that
> ignores leap seconds (2.2.2.77). Use of this algorithm by the
> time manipulation functions of the C Standard is mandated in 8.1.
I may as well point out again that these requirements are mutually
contradictory. As soon as you talk specifically about UTC rather than
some other flavor of UT, you are requiring leap seconds to be taken
into account. However, I'm informed that the intent clearly was to
require that they be ignored.
Someone else asked when leap seconds happen. There is not a pre-set
schedule; it depends on the measured rotation of the Earth. At the
moment they tend to be roughly every 2 years.
--
Mark Brader, m...@sq.com "Logic is logic. That's all I say."
SoftQuad Inc., Toronto -- Oliver Wendell Holmes
My text in this article is in the public domain.
Bill Marcum
Jonathan Kamens <j...@annex-1-slip-jik.cam.ov.com> wrote:
>In article <DqECI...@iglou.com>, bma...@iglou.iglou.com (Bill Marcum) writes:
>|> What is the algorithm for leap seconds anyway? Are they used in years
>|> ending with 00, or only years divisible by 400?
>
>There is no "algorithm". A leap second is inserted or removed when the body
>which governs such things determines that it is necessary to do so in order to
>bring our clocks into sync with the rotation of the Earth.
>
leap seconds? When they occur, aren't they handled by manually resetting
the system clock (or automatically, if you have some sort of time server)?
Bob Goudreau
: There is no "algorithm". A leap second is inserted or removed when the body
: which governs such things determines that it is necessary to do so in order to
: bring our clocks into sync with the rotation of the Earth.
What do you mean by "removing" leap seconds?
----------------------------------------------------------------------
Bob Goudreau Data General Corporation
goud...@dg-rtp.dg.com 62 Alexander Drive
+1 919 248 6231 Research Triangle Park, NC 27709, USA
Paul Eggert
bma...@iglou.iglou.com (Bill Marcum) writes:
> why should the OS make any special allowance for leap seconds?
> When they occur, aren't they handled by manually resetting the system clock
In some applications, it's convenient if the real-time difference
between two time()-return-values S and T is (S - T) seconds.
If you artificially reset the system clock at every leap second,
you lose this relationship.
Posix 1003.1-1990 does not allow for such applications,
since Posix requires that the clock ignore leap seconds,
but if you're willing to run in non-Posix mode,
many operating systems support leap seconds.
I believe BSDI, FreeBSD, Linux, NetBSD, and SunOS all support
leap seconds if you're willing to configure them correctly;
see the -l option to the zic command.
Geoff Clare
I'm surprised nobody has mentioned the following important point yet:
The POSIX no-leap-second restriction only applies to gmtime(), and to
localtime() and mktime() when used with TZ=UCT0. It allows time-related
functions other than gmtime() to account for leap seconds when TZ has
other values (such as TZ=GMT0BST, or I think even with TZ=GMT0).
--
Geoff Clare <g...@root.co.uk>
UniSoft Limited, London, England.
Bill Owen
In article <4loe9f$d...@dg-rtp.dg.com>, goud...@dg-rtp.dg.com (Bob Goudreau) writes:
> Jonathan Kamens (j...@annex-1-slip-jik.cam.ov.com) wrote:
> : There is no "algorithm". A leap second is inserted or removed when the body
> : which governs such things determines that it is necessary to do so in order to
> : bring our clocks into sync with the rotation of the Earth.
>
> What do you mean by "removing" leap seconds?
The formal mechanism allows for "negative leap seconds", i.e. for the 60th
second of a minute to be removed. This eventuality has not been necessary
since leap seconds were introduced in 1972.
-- Bill Owen, w...@wansor.jpl.nasa.gov
Jonathan Kamens
In article <4loe9f$d...@dg-rtp.dg.com>, goud...@dg-rtp.dg.com (Bob Goudreau) writes:
|> Jonathan Kamens (j...@annex-1-slip-jik.cam.ov.com) wrote:
|> : There is no "algorithm". A leap second is inserted or removed when the body
|> : which governs such things determines that it is necessary to do so in order to
|> : bring our clocks into sync with the rotation of the Earth.
|>
|> What do you mean by "removing" leap seconds?
1) What does this question have to do with comp.unix.programmer? The fact
that you do not read sci.astro is not a reasonable justification for
continuing to post off-topic articles in comp.unix.programmer. If you have
some interest in the thread and you want to keep following it, then subscribe
to sci.astro temporarily.
2) The leap-second system doesn't only involve *adding* seconds, it also
involves *deleting* them. That is, if the rotation of the Earth is slower
than our clocks think it's supposed to be, then we have to add a second
occasionally to keep our clocks in sync with the Earth. However, if the
rotation is *faster* than our clocks think it's supposed to be, then we have
to *remove* a second to keep our clocks in sync.
I don't believe we've actually done the latter since the leap-second system
was instituted (although I could be wrong), but there are provisions for it if
it should ever become necessary.
Followups once again directed to sci.astro.
Thomas A. McGlynn
Bob Goudreau wrote:
>
> Jonathan Kamens (j...@annex-1-slip-jik.cam.ov.com) wrote:
> : There is no "algorithm". A leap second is inserted or removed when the body
> : which governs such things determines that it is necessary to do so in order to
> : bring our clocks into sync with the rotation of the Earth.
>
> What do you mean by "removing" leap seconds?
>
> Bob Goudreau Data General Corporation
> goud...@dg-rtp.dg.com 62 Alexander Drive
> +1 919 248 6231 Research Triangle Park, NC 27709, USA
In principle, we can have a day which is 86399 seconds long.
This has never happened so far as I know, but we're ready
if the earth's rotation starts speeding up. I believe the
second to be omitted would be 23:59:59-24:00:00 of either
June 30 or December 31, but it might be the first second of the
next day.
Tom McGlynn
t...@silk.gsfc.nasa.gov
Guy Harris
Paul Eggert <egg...@twinsun.com> wrote:
>In some applications, it's convenient if the real-time difference
>between two time()-return-values S and T is (S - T) seconds.
>If you artificially reset the system clock at every leap second,
>you lose this relationship.
>
>Posix 1003.1-1990 does not allow for such applications,
>since Posix requires that the clock ignore leap seconds,
Actually, 1003.1b-1993 and, I think, 1003.1-1990 are arguably
self-contradictory in this matter. 1003.1b-1993 says
2.2.2.106 seconds since the Epoch: A value to be interpreted as
the number of seconds between a specified time and the Epoch.
and defines the Epoch as:
2.2.2.32 Epoch: The time 0 hours, 0 minutes, 0 seconds, Januray
1, 1970, Coordinated Universal Time.
which could be read as implying that "seconds since the Epoch" increases
by one every second, regardless of leap seconds, thus making the
real-time difference between two "time()" return values S and T (S-T)
seconds, but 2.2.2.106 also says:
A Coordinated Universal Time name (specified in seconds
(tm_sec), minutes (tm_min), hours (tm_hour), days since January
1 of the year (tm_yday), and calendar year minus 1900 (tm_year)
is related to a time represented as seconds since the Epoch,
according to the expression below:
If the year < 1970 or the value is negative, the relationship is
undefined. If the year >= 1970 and the value is nonnegative,
the value is related to a Coordinated Universal Time name
according to the expression:
tm_sec + tm_min*60 + tm_hour*3600 + tm_yday*86400+
(tm_year-70)*31536000 + ((tm_year-69)/4)*86400
which I think might imply that "seconds since the Epoch" can't count the
number of seconds since the Epoch, if a UTC name for a leap second has
"tm_sec" equal to 60, as the UTC value
1977-12-31 23:59:60
would turn into a "time_t" of
60 + 59*60 + 23*3600 + 364*86400+ 7*31536000 + 2*86400
or 252460800, and what I think is the UTC value for the next second:
1978-01-01 00:00:00
would turn into a "time_t" of
0 + 0*60 + 0*3600 + 0*86400 + 8*31536000 + 2*86400
or 252460800, meaning you *do* have to shift the clock backwards.
The 1003.1b-1993 Rationale says:
Most systems' notion of "time" is that of a continuously
increasing value, so this value should increase even during leap
seconds. However, not only do most systems not keep track of
leap seconds, but most systems are probably not synchronized to
any standard time reference. Therefore, it is inappropriate to
require that a time represented as seconds since the Epoch
precisely represent the number of seconds between the referenced
time and the Epoch.
which doesn't seem to clearly state whether "seconds since the Epoch"
should increase during leap seconds or not - the first sentence seems to
say it should, but the second sentence mentions, for some reason, leap
seconds, but without explicitly stating that it should *not* increase
during leap seconds.
Later, though, it asserts:
It is important that the interpretation of time names and
"seconds since the Epoch" values be consistent across conforming
systems. That is, it is important that all conforming systems
intepret "536 457 599 seconds since the Epoch" as 59 seconds, 59
minutes, 23 hours 31 December 1986, regardless of the accuracy
of the system's idea of the current time. The expression is
given to assure a consistent interpretation, not to attempt to
specify the calendar. The relationship between "tm_yday" and
the day of week, day of month, and month is presumed to be
specified elsewhere and is not given in POSIX.1.
Consistent interpretation of "seconds since the Epoch" can be
critical to certain types of distributed applications that rely
on such timestamps to synchronize events. The accural of leap
seconds in a time standard is not predictable. The number of
leap seconds since the Epoch will likely increase. POSIX.1 is
more concerned about the synchronization of time between
applications of astronomically short duration. These concerans
are expected to be more critical in the future.
However, *I* sure wouldn't recommend writing such an application to use
time stamps represented as UTC names; *I*'d recommend using seconds
since some particular fixed instant in time (not necessarily the Epoch,
given that, for example, the Internet Time Protocol (RFC868) uses
seconds since 00:00:00 UTC, January 1, 1900). Given that, leap seconds
simply don't become an issue.
I.e., I'm not sure why any sanely-written distributed application
relying on timestamps to synchronize events should *care* about leap
seconds, and, as such, am not sure why POSIX needed to specify anything
about them (other than specifying that they *should* be taken into
account, and pointing to the Olson code as an implementation that *does*
take them into account, when converting between "time_t"s and "struct
tm"s).
>but if you're willing to run in non-Posix mode,
>many operating systems support leap seconds.
>I believe BSDI, FreeBSD, Linux, NetBSD, and SunOS all support
>leap seconds if you're willing to configure them correctly;
>see the -l option to the zic command.
SunOS 4.x and, as far as I know, 5.x *don't* support leap seconds. (In
retrospect, I should've left the leap-second code in there, and said "we
don't provide leap seconds files because the POSIX folks have said, for
some reason for which they don't appear to have provided any factual
support, 'POSIX systems should pretend that leap seconds don't exist'",
or something such as that, in the man page.)
Chris Carrier
Perhaps someone could tell us the dates from the time leap seconds began until
the present when leap seconds were proclaimed, and also the present difference
between Universal and Ephemeris Time?
Bill Owen
Here's a table of UTC - TDT, beginning with the introduction of the redefined
UTC on 1972 Jan 1. The interval over which each value is valid begins at the
time to its left. (If I could move the values of UTC - TDT down half a line,
it might make better sense.) The current value is 62.184 s.
1972 JAN 42.184
1972 JUL 43.184
1973 JAN 44.184
1974 JAN 45.184
1975 JAN 46.184
1976 JAN 47.184
1977 JAN 48.184
1978 JAN 49.184
1979 JAN 50.184
1980 JAN 51.184
1981 JUL 52.184
1982 JUL 53.184
1983 JUL 54.184
1985 JUL 55.184
1988 JAN 56.184
1990 JAN 57.184
1991 JAN 58.184
1992 JUL 59.184
1993 JUL 60.184
1994 JUL 61.184
1996 JAN 62.184
-- Bill Owen, w...@wansor.jpl.nasa.gov
Bill Owen
In article <318138...@silk.gsfc.nasa.gov>, "Thomas A. McGlynn" <t...@silk.gsfc.nasa.gov> writes:
> In principle, we can have a day which is 86399 seconds long.
> This has never happened so far as I know, but we're ready
> if the earth's rotation starts speeding up. I believe the
> second to be omitted would be 23:59:59-24:00:00 of either
> June 30 or December 31, but it might be the first second of the
> next day.
This is correct -- the second that would be omitted is the last second of
the month.
In principle leap seconds can be placed at the end of *any* month, but in
practice they have always been at the end of June or December.
And it's correct that there have been no "negative leap seconds" yet.
-- Bill Owen, w...@wansor.jpl.nasa.gov
Bob Goudreau
Jonathan Kamens (j...@annex-1-slip-jik.cam.ov.com) wrote:
: In article <4loe9f$d...@dg-rtp.dg.com>, goud...@dg-rtp.dg.com (Bob Goudreau) writes:
: |> : There is no "algorithm". A leap second is inserted or removed when the body
: |> : which governs such things determines that it is necessary to do so in order to
: |> : bring our clocks into sync with the rotation of the Earth.
: |>
: |> What do you mean by "removing" leap seconds?
: 1) What does this question have to do with comp.unix.programmer? The fact
: that you do not read sci.astro is not a reasonable justification for
: continuing to post off-topic articles in comp.unix.programmer. If you have
: some interest in the thread and you want to keep following it, then subscribe
: to sci.astro temporarily.
Don't get your panties in a bunch. What it has to do with c.u.p is
the same topic mentioned earlier in this thread: How are UNIX system
utilities supposed to accommodate the vagaries of leap seconds? Just
because you felt the need to redirect followups away from the original
newsgroup doesn't mean that the rest of us need follow your dictate.
: 2) The leap-second system doesn't only involve *adding* seconds, it also
: involves *deleting* them. That is, if the rotation of the Earth is slower
: than our clocks think it's supposed to be, then we have to add a second
: occasionally to keep our clocks in sync with the Earth. However, if the
: rotation is *faster* than our clocks think it's supposed to be, then we have
: to *remove* a second to keep our clocks in sync.
There's nothing surprising about that, but the practice you describe
does *not* fall under the heading of Leap Second Removal. What you
are talking about is the removal of an *ordinary* second. (A leap
second could be removed only if it existed in the first place!) When
you first broached the topic of removing leap seconds, I thought you
were referring to some sort of process wherein leap seconds that had
been previously added to the calendar were later removed retroactively.
I am gratified to discover that this is not the case.
At any rate, has any work been done on incorporating the addition
(and removal) of seconds into standard UNIX time libraries? I would
think that the Olsen approach of isolating non-algorithmic timezone
information into files that can be examined by the appropriate
library routines would also be a good way to identify which minutes
get 61 (or 59) seconds. As with the timezone data, the leap second
table would have to be updated periodically to accommodate the latest
batch of administrative decrees on the subject.
Enrique Duran
goud...@dg-rtp.dg.com (Bob Goudreau) wrote:
>Jonathan Kamens (j...@annex-1-slip-jik.cam.ov.com) wrote:
>: In article <4loe9f$d...@dg-rtp.dg.com>, goud...@dg-rtp.dg.com (Bob Goudreau) writes:
>: |> : There is no "algorithm". A leap second is inserted or removed when the body
>: |> : which governs such things determines that it is necessary to do so in order to
>: |> : bring our clocks into sync with the rotation of the Earth.
>: |>
>: |> What do you mean by "removing" leap seconds?
>Bob Goudreau Data General Corporation
>goud...@dg-rtp.dg.com 62 Alexander Drive
>+1 919 248 6231 Research Triangle Park, NC 27709, USA
help myself!
Paul Schlyter
In article <4m1ih7$t4f$1...@mhadf.production.compuserve.com>,
Chris Carrier <72157...@CompuServe.COM> wrote:
> Perhaps someone could tell us the dates from the time leap seconds
> began until the present when leap seconds were proclaimed, and also
> the present difference between Universal and Ephemeris Time?
distributed worldwide.
UTC = Coordinated Universal Time. Differs from TAI by an integral
number of seconds. When needed, leap seconds are introduced in UTC
to keep the difference between UTC and UT less than 0.9 s.
UTC was introduced in 1972.
UT = Universal time. Defined by the Earth's rotation, and determined
by astronomical observations. This time scale is slightly irregular.
There are several different definitions of UT, but the difference
between them is always less than about 0.03 s. Usually one means
UT2 when saying UT. UT2 is UT corrected for pole wandering, and
seasonal variations in the Earth's rotational speed.
ET = Ephemeris Time. Was used 1960-1983, and was replaced by TDT and TDB
in 1984. For most purposes, ET up to 1983 Dec 31 and TDT from 1984
Jan 1 can be regarded as a continuous time-scale.
TDT = Terrestial Dynamical Time. Used as a time-scale of ephemerides
from the Earth's surface. TDT = TAI + 32.184. Formerly called
ET, Ephemeris Time.
TDB = Barycentric Dynamical Time. Used as a time-scale of ephemerides
referred to the barycentre of the solar system. Differs from TDT
by at most a few milliseconds.
TT = Terrestial Time. Used instead of TDT or TDB when the difference
between them doesn't matter.
GMT = Greenwich Mean Time. It's ambiguous, and is now used (although
not in astronomy) in the sense of UTC in addition to the earlier
sense of UT. Prior to 1925, it was reckoned for astronomical
purposes from Greenwich mean noon (12h UT)
TDT = TAI+32.184s ==> UT-UTC = TAI-UTC - (TDT-UT) + 32.184s
Starting at TAI-UTC TDT-UT UT-UTC
1972-01-01 +10 +42.23 -0.05
1972-07-01 +11 +42.80 +0.38
1973-01-01 +12 +43.37 +0.81
1973-07-01 " +43.93 +0.25
1974-01-01 +13 +44.49 +0.69
1974-07-01 " +44.99 +0.19
1975-01-01 +14 +45.48 +0.70
1975-07-01 " +45.97 +0.21
1976-01-01 +15 +46.46 +0.72
1976-07-01 " +46.99 +0.19
1977-01-01 +16 +47.52 +0.66
1977-07-01 " +48.03 +0.15
1978-01-01 +17 +48.53 +0.65
1978-07-01 " +49.06 +0.12
1979-01-01 +18 +49.59 +0.59
1979-07-01 " +50.07 +0.11
1980-01-01 +19 +50.54 +0.64
1980-07-01 " +50.96 +0.22
1981-01-01 " +51.38 -0.20
1981-07-01 +20 +51.78 +0.40
1982-01-01 " +52.17 +0.01
1982-07-01 +21 +52.57 +0.61
1983-01-01 " +52.96 +0.22
1983-07-01 +22 +53.38 +0.80
1984-01-01 " +53.79 +0.39
1984-07-01 " +54.07 +0.11
1985-01-01 " +54.34 -0.16
1985-07-01 +23 +54.61 +0.57
1986-01-01 " +54.87 +0.31
1986-07-01 " +55.10 +0.08
1987-01-01 " +55.32 -0.14
1987-07-01 " +55.57 -0.39
1988-01-01 +24 +55.82 +0.36
1988-07-01 " +56.06 +0.12
1989-01-01 " +56.30 -0.12
1989-07-01 " +56.58 -0.40
1990-01-01 +25 +56.86 +0.32
1990-07-01 " +57.22 -0.04
1991-01-01 +26 +57.57 +0.61
1991-07-01 " +57.94 +0.24
1992-01-01 " +58.31 -0.13
1992-07-01 +27 +58.72 +0.46
1993-01-01 " +59.12 +0.06
1993-07-01 +28 +59.55 +0.63
1994-01-01 " +59.98 +0.20
1994-07-01 +29 +60.3 +0.9
1995-01-01 " +60.6 +0.6
1995-07-01 " +60.9 +0.3
1996-01-01 +30 +61.2 +1.0
1996-07-01 " +61.5 +0.7
For the latest status concerning leap seconds in UTC, send e-mail to
ads...@tycho.usno.navy.mil with a Subject: line of 'leap' and no
text. You will receive in reply a list of past and provisional future
leap seconds.
--
----------------------------------------------------------------
Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
e-mail: pau...@saaf.se p...@home.ausys.se
Stephen Baynes
[Followups to comp.unix.programer only]
Bob Goudreau (goud...@dg-rtp.dg.com) wrote:
: Jonathan Kamens (j...@annex-1-slip-jik.cam.ov.com) wrote:
: : In article <4loe9f$d...@dg-rtp.dg.com>, goud...@dg-rtp.dg.com (Bob Goudreau) writes:
: At any rate, has any work been done on incorporating the addition
: (and removal) of seconds into standard UNIX time libraries? I would
: think that the Olsen approach of isolating non-algorithmic timezone
: information into files that can be examined by the appropriate
: library routines would also be a good way to identify which minutes
: get 61 (or 59) seconds. As with the timezone data, the leap second
: table would have to be updated periodically to accommodate the latest
: batch of administrative decrees on the subject.
I can see this causing problems. If a program calculates some time in the
future using a particular version of the leap second table, and then the
table is updated then the calculation could be invalidated. One would need
probably need to keep real-times(including leap seconds) separate from
calendar-times(excluding leap seconds) and be careful about which one is
working with.
--
Stephen Baynes bay...@ukpsshp1.serigate.philips.nl
Philips Semiconductors Ltd
Southampton My views are my own.
United Kingdom
Are you using ISO8859-1? Do you see © as copyright, ÷ as division and ½ as 1/2?
Paul Schlyter
In article <4m5l3t$c...@dg-rtp.dg.com>,
Bob Goudreau <goud...@dg-rtp.dg.com> wrote:
> At any rate, has any work been done on incorporating the addition
> (and removal) of seconds into standard UNIX time libraries?
off by at least several tens of seconds, and to worry about leap
seconds in such a situation seems to not be worthwhile.
Also, why should one assume that the UNIX time system is in UTC? It
could just as well be assumed to be another time system, without leap
seconds, such as UT0/1/2, TT or TAI.
Joe Seigh
In article <4mbq15$q...@electra.saaf.se>, pau...@electra.saaf.se (Paul Schlyter) writes:
|> Also, why should one assume that the UNIX time system is in UTC? It
|> could just as well be assumed to be another time system, without leap
|> seconds, such as UT0/1/2, TT or TAI.
|>
The "unix time system" isn't in anything. There's just this thing called
an epoch which is really just an instant in time which you can specify in
any time system you choose to. In UTC it's 00:00:00 Jan 1, 1970. The
time() system call just returns the number of seconds from that instant in
time.
All the confusion arises because the timestamp conversion routines, which
convert the time() value (number of seconds from the epoch) to a UTC +-
timezone offset expression, don't take leap seconds into account,
so we and things like network time (synching) protocols adjust the unix
epoch rather than fix the timestamp conversion routines.
The so called epoch is really 00:00:20 Jan 1, 1970 UTC at this
point (if I counted those leap seconds correctly).
--
Joe Seigh se...@bose.com
--
Joe Seigh se...@bose.com
Paul D. Smith
%% pau...@electra.saaf.se (Paul Schlyter) writes:
ps> In article <4m5l3t$c...@dg-rtp.dg.com>,
ps> Bob Goudreau <goud...@dg-rtp.dg.com> wrote:
>> At any rate, has any work been done on incorporating the addition
>> (and removal) of seconds into standard UNIX time libraries?
ps> Would it be worth the trouble? After all, computer clocks are
ps> usually off by at least several tens of seconds, and to worry
ps> about leap seconds in such a situation seems to not be
ps> worthwhile.
Aha! Obviously a time-newbie! :)
In fact, any shop where they care about such things (which should be,
but isn't, all of them) will be running NTP (Network Time Protocol) on
their network, and syncing all their system clocks together--and to
either a radio clock locally or some system(s) on the Internet which has
them.
You should get offsets on the order of (much?) less than a second using
this method... and every host has the same time. An absolute must for
any shop that uses timestamps as important info.
See comp.protocols.time.ntp or http://www.eecis.udel.edu/~ntp/ for more
details.
ps> Also, why should one assume that the UNIX time system is in UTC?
ps> It could just as well be assumed to be another time system,
ps> without leap seconds, such as UT0/1/2, TT or TAI.
No, it couldn't. UNIX time has been defined to be based on UTC (GMT)
since the early 1970's, AFAIK. Certainly every UNIX system I've ever
worked on (since 1984) has been. This is now formalized in POSIX, as
well. To be more specific, when you call the UNIX time system calls,
the value you get back is always given as UTC (or local time, defined
as an offset to UTC).
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
Senior Software Engineer Bay Networks, Inc.
-----------------------------------------------==<http://www.baynetworks.com/>-
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions--Bay Networks takes no responsibility for them.
Chris Franks
Paul Schlyter wrote:
>
> In article <4m5l3t$c...@dg-rtp.dg.com>,
> Bob Goudreau <goud...@dg-rtp.dg.com> wrote:
>
> > At any rate, has any work been done on incorporating the addition
> > (and removal) of seconds into standard UNIX time libraries?
>
> off by at least several tens of seconds, and to worry about leap
> seconds in such a situation seems to not be worthwhile.
>
> Also, why should one assume that the UNIX time system is in UTC? It
> could just as well be assumed to be another time system, without leap
> seconds, such as UT0/1/2, TT or TAI.
>
> ----------------------------------------------------------------
> Paul Schlyter, Swedish Amateur Astronomer's Society (SAAF)
> Grev Turegatan 40, S-114 38 Stockholm, SWEDEN
principal
scientist, who was the project manager for the 5071A Primary Frequency
Standard:
This is to clarify your impression that there are "about a dozen atomic
clocks
distributed worldwide."
==========================================================================
UTC, or Universal Coordinated Time, the World's Clock, is derived
from measurements on atomic clocks and by astronomical
observations. UTC is coordinated by the Bureau International des
Poids et Mesures (BIPM) in Paris.
The time interval, the second, is determined by collecting
results from a wide variety of cesium standards and hydrogen
masers. This is called the atomic second and is the base for the
TAI, or Atomic International Time.
I just finished analyzing the latest TAI stability data from
BIPM.
As of December 28,1995, the HP 5071A Primary Frequency Standard
became the dominant part of the BIPM timebase. Of the 176
weighted clocks, exactly one-half, or 88, are HP 5071A units, 76
high performance, and 12 standard performance.
The 88 clocks are 50% of the total but contribute 71.1% of the total
weight in the BIPM timebase.
If we also add the 44 HP 5061A/B clocks, we have 75% of the
weighted clocks and 82.3% of the total weight. This is an
all-time dominance of TAI. The earlier HP atomic clocks, the
5060A, 5061A, and 5061B never achieved this milestone.
In an abstract of an invited paper to be presented to the 1996
International Frequency Control Symposium, Madame Claudine
Thomas, the director of timing services at the BIPM, states that
"Since the end of 1992, the quality of timing data received at
the BIPM has evolved rapidly thanks to the extensive replacement
of older designs of commercial caesium clocks by the new HP 5071A
units." Her talk goes on to document almost an order of
magnitude improvement in the stability of the atomic second
because of the new standards.
--
Speaking for myself from experience
Chris Carrier
In the Newsgroups: sci.astro,comp.unix.programmer, w...@wansor.jpl.nasa.gov
(Bill Owen) wrote on the Subject: When do leap seconds occur? (was: Re:
gmtime(): Doesn't account for leap seconds?!) on 29 Apr 1996 16:51:51 GMT
UTC and TDT is incremented in one second intervals, why do they maintain a
fractional difference of .184 second instead of using integral seconds?
The lack of a physical model for the long term rotation of the Earth can make
things hairy in planetarium programs; one thing that I use to check the
accuracy of planetaria is to check out the Sun on 5900 Jul 11 Wed 20:46 TDT;
at that time (according to Meeus, Venus will be in the exact center of the Sun
"the least distance of the centers, which will be approximately zero at 20h
46m (Ephemeris Time)" during the transit. My planetarium (the old ATARI)
showed Venus transiting the Sun on that day, but not centrally and 4h 30m
earlier than Meeus.
Personally I think planetarium should use TDT (former Ephemeris Time) for
computing motions of other planets and UTC for determining altaazimuth
coordinates; a time in the distant past or future, such as the abovementioned
Meeusian date, should be read as TDT for RA and Dec.
Chris Carrier
PS: I thought we had a leap second on February 29th once?
Paul Schlyter
In article <p5ivedm...@lemming.wellfleet.com>,
Paul D. Smith <psm...@wellfleet.com> wrote:
> %% pau...@electra.saaf.se (Paul Schlyter) writes:
>
> ps> In article <4m5l3t$c...@dg-rtp.dg.com>,
>
> >> At any rate, has any work been done on incorporating the addition
> >> (and removal) of seconds into standard UNIX time libraries?
>
> ps> usually off by at least several tens of seconds, and to worry
> ps> about leap seconds in such a situation seems to not be
> ps> worthwhile.
>
> Aha! Obviously a time-newbie! :)
fractions of a second, and then I do also have to consider the
differences between the various flavors of UT (i.e. UTC and UT2).
> In fact, any shop where they care about such things (which should be,
> but isn't, all of them)
clock of one second would not be important.
> will be running NTP (Network Time Protocol) on
> their network, and syncing all their system clocks together--and to
> either a radio clock locally or some system(s) on the Internet which has
> them.
>
> You should get offsets on the order of (much?) less than a second using
> this method... and every host has the same time. An absolute must for
> any shop that uses timestamps as important info.
>
> See comp.protocols.time.ntp or http://www.eecis.udel.edu/~ntp/ for more
> details.
>
> ps> Also, why should one assume that the UNIX time system is in UTC?
> ps> It could just as well be assumed to be another time system,
> ps> without leap seconds, such as UT0/1/2, TT or TAI.
>
> No, it couldn't. UNIX time has been defined to be based on UTC (GMT)
and has no unambiguous definition, therefore the term 'GMT' should be
avoided. Traditionally, GMT was the same as UT2, but nowadays many
people seem to believe GMT is the same as UTC - thus GMT means
different things to different people, whereas everybody agree on the
definition of e.g. UTC and UT2. Therefore the term 'GMT' should be
used only when the difference between UTC and UT2 doesn't matter,
i.e. when one need not worry about leap seconds. And since we're
discussing leap seconds, we cannot ignore the difference between UTC
and UT2 here....
> since the early 1970's, AFAIK.
> Certainly every UNIX system I've ever worked on (since 1984) has been.
fraction of a second ... I find that hard to believe.
> This is now formalized in POSIX, as well.
pretend that there are no leap seconds in UTC?
> To be more specific, when you call the UNIX time system calls,
> the value you get back is always given as UTC (or local time, defined
> as an offset to UTC).
difftime() cannot be trusted to return an accurate value. And if
used on future dates, it can never return accurate values, since leap
seconds cannot be predicted, and we cannot know exactly what the UTC
will be like, more than perhaps half-a-year in advance. Thus
difftime() ought to be programmed such that it returns an error
indicator if used on date intervals where it's not yet known where
the leap seconds will call. And in your locale you should be able to
specify that you want the time given in, say, UT2, TT, or TAI instead,
since then you can trust the results from difftime() and friends.
---------------------------------------------------------------------
The UNIX time functions are useful only when you need not deal with
dates prior to 1970, and when you need no better precision than 1
second.
Paul Eggert
pau...@electra.saaf.se (Paul Schlyter) writes:
> Does POSIX also formalize how to handle leap seconds?
Yes. Posix requires that you ignore leap seconds, in the sense that time_t
values count the number of seconds since the Epoch, ignoring leap seconds.
By the way, Posix erroneously says that the Epoch is 1970-01-01 00:00:00 UTC,
a time that never existed (since UTC began in 1972).
The Posix specifiers were not expert about time....
> This means that unless leap seconds are accounted for, the function
> difftime() cannot be trusted to return an accurate value.
As far as I can tell, it would be valid for a Posix implementation of
difftime to account for leap seconds. I don't know of any that do,
however: they all just subtract time_t values. Perhaps you could propose
an enhancement to the free tz implementation (see
ftp://elsie.nci.nih.gov/pub/tz*). It already has an option to support
leap seconds in a non-Posix-compliant way (see below),
but this has proved less than popular because of the dead hand of Posix,
and perhaps there's a better way that's more Posix-compliant.
(Alas, the only ways that I can see require help from the underlying
system calls, though.)
> And in your locale you should be able to
> specify that you want the time given in, say, UT2, TT, or TAI instead,
> since then you can trust the results from difftime() and friends.
That _is_ supported by the free tz implementation. For example,
in BSD/OS 1.1 I can set my TZ environment variable to
'right/US/Pacific', and then time_t values will use TAI
(plus a Unix-friendly offset). This doesn't conform to Posix, though.
Paul Schlyter
In article <318A7D...@sc.hp.com>, Chris Franks <cfr...@sc.hp.com> wrote:
> This is to clarify your impression that there are "about a dozen atomic
> clocks distributed worldwide."
Obviously things have happened since then......
Paul Schlyter
In article <4meqmp$kj8$1...@mhade.production.compuserve.com>,
> between UTC and TDT is incremented in one second intervals, why do they
> maintain a fractional difference of .184 second instead of using integral
> seconds?
by an integral number of seconds, and the difference TAI - TT is not
an integral number of seconds.
Paul Schlyter
In article <4mggpt$7...@white.twinsun.com>,
Paul Eggert <egg...@twinsun.com> wrote:
> pau...@electra.saaf.se (Paul Schlyter) writes:
>
>> Does POSIX also formalize how to handle leap seconds?
>
> values count the number of seconds since the Epoch, ignoring leap seconds.
>
> By the way, Posix erroneously says that the Epoch is 1970-01-01 00:00:00 UTC,
> a time that never existed (since UTC began in 1972).
> The Posix specifiers were not expert about time....
bogus, for the two reasons above: leap seconds are not implemented in
time_t, and the origin is at an instant when UTC did not exist.
>> This means that unless leap seconds are accounted for, the function
>> difftime() cannot be trusted to return an accurate value.
>
> difftime to account for leap seconds. I don't know of any that do,
minute of 1995, when a leap second was inserted. Since time_t is supposed
to ignore leap seconds, this means that:
1995-Dec-31 23:59:60
and
1996-Jan-01 00:00:00
would both receive 820454400 as the value for time_t. Thus, any
conceivable implementation of difftime() would, when receiving this
value of time_t, be unable to decide whether it does refer to
1995-Dec-31 at 23:59:60 or 1996-Jan-01 at 00:00:00 -- therefore in
such a case it could never be guaranteed to return the correct time
difference. In particular, computing the time difference between
1995-Dec-31 at 23:59:60 and 1996-Jan-01 at 00:00:00 would always
give 0 seconds, even though the real difference would be 1 second,
since both these instants would have been assigned the same time_t.
> however: they all just subtract time_t values. Perhaps you could propose
> an enhancement to the free tz implementation (see
> ftp://elsie.nci.nih.gov/pub/tz*). It already has an option to support
> leap seconds in a non-Posix-compliant way (see below),
> but this has proved less than popular because of the dead hand of Posix,
> and perhaps there's a better way that's more Posix-compliant.
> (Alas, the only ways that I can see require help from the underlying
> system calls, though.)
and replaced by "the time is in UT2". This solves both problems
described in the beginning of this message: UT2 has no leap seconds,
and UT2 did exit on 1 Jan 1970 (and much earlier than that). The
difference is hardly significant, since the time_t variable has a
resolution of 1 second, and UTC and UT2 never should differ by more
than 0.9 seconds, but it would also relieve people from futile
attempts to try to somehow account for leap seconds.
Any application that really would need to account for leap seconds
would probably also need to account for the difference between UTC
and UT2 -- such an application would need a time source with both
greater resolution and greater accuracy than the UNIX time_t
variable. Apart from having your own atomic clock, the best way to
do this would be to connect a time signal receiver to your computer.
Time signals give the time in UTC, but they also usually contain
information about the current difference between UTC and both TAI
(always an integral number of seconds) and UT2 (to the nearest 0.1
second). And, yes, if there is a leap second at the end of a year
(or a half-year), that final minute _will_ contain 61 seconds in the
broadcast time signal.
Matthew Francey
pau...@electra.saaf.se (Paul Schlyter) wrote:
>I would suggest that the requirement "the time is in UTC" is dropped
>and replaced by "the time is in UT2".
First of all, lets be totally clear from the start: leap seconds are a
*user interface* issue. They only exist to maintain some a lock
between our best time-pieces and the wobbly rotation of the Earth and the
sense of "time" the creatures that happen to inhabit it. Like us. And
(do I have to say it?), user interface crap doesn't belong in operating
system kernels.
Ok.
The "problem" with UTC not existing in 1970 is pedantic -- like, who cares?
If it is such a big deal, then I reckon that the use of the "Julian Day" be
deemed equally bogus, since the Julian calendar simply did not exist
in 4713BC.
So, no (or maybe I will yell it: NO!), the time_t should not be in UT2.
The reason is that *all* implementations of the time_t is that of a
continuously increasing counter. One click per second. So when 1996
rolled in, I am totally confident that not one single "POSIX compliant"
(assuming such a thing exists) computer system anywhere halted its counter
for a single second, in due respect to Ye Olde POSIX Standard, with maybe
a touch of reverence for the Leap Second itself.
So if any redefinitions are to be made, I'd say it would be more appropriate
to redefine time_t to be in TDT (or, better yet, lets think ahead: TDB).
Looking at my copy of the POSIX spec [ya I know: get a life :-/], and the
equation they give, this "fits" alot better. And we do not surrender the
fundamental notion that the ticks of the time_t are real, honest-to-god
hard "seconds" as experienced by the computer -- not the squishy,
variable-length seconds of UT2.
That in hand, we proceed to add, or modify, an entry point that can provide
the current value of delta-T, delta-UTC, etc. And then move on to modify
ctime(), localtime(), etc, to use this information to present the time
in whatever format the caller wishes. Where such transformations belong.
-mdf
Bill Owen
In article <4meqmp$kj8$1...@mhade.production.compuserve.com>, Chris Carrier <72157...@CompuServe.COM> writes:
> I wonder, though; since the difference between
> UTC and TDT is incremented in one second intervals, why do they maintain a
> fractional difference of .184 second instead of using integral seconds?
"Althought TAI was officially introduced in January 1972, it has been available
since July 1955" according to the _Explanatory Supplement_ (page 40). My
understanding is that it really came on-line in 1958, at which time it was set
to what was then known as Universal Time ("Coordinated Universal Time" or UTC
wasn't adopted until 1972). The difference between ET and UT in January '58
was later determined to have been 32.184 seconds. Consequently TAI lags TDT
(the successor to ET) by 32.184 seconds, and UTC lags TDT by (32.184 + N)
seconds, where N is the accumulated number of leap seconds -- currently 20.
> The lack of a physical model for the long term rotation of the Earth can make
> things hairy in planetarium programs; one thing that I use to check the
> accuracy of planetaria is to check out the Sun on 5900 Jul 11 Wed 20:46 TDT;
> at that time (according to Meeus, Venus will be in the exact center of the Sun
> "the least distance of the centers, which will be approximately zero at 20h
> 46m (Ephemeris Time)" during the transit. My planetarium (the old ATARI)
> showed Venus transiting the Sun on that day, but not centrally and 4h 30m
> earlier than Meeus.
>
> Personally I think planetarium should use TDT (former Ephemeris Time) for
> computing motions of other planets and UTC for determining altaazimuth
> coordinates; a time in the distant past or future, such as the abovementioned
> Meeusian date, should be read as TDT for RA and Dec.
True enough. This is exactly why time measurements were bifurcated into UT
and ET originally -- the earth's rotation is too irregular to be used as the
independent variable in the planetary equations of motion.
> Chris Carrier
>
>
> PS: I thought we had a leap second on February 29th once?
>
Possible under the rules, but it hasn't happened.
-- Bill Owen, w...@wansor.jpl.nasa.gov
Bob Goudreau
In article <Dqrq7...@ukpsshp1.serigate.philips.nl>,
bay...@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
: : At any rate, has any work been done on incorporating the addition
: : (and removal) of seconds into standard UNIX time libraries? I would
: : think that the Olsen approach of isolating non-algorithmic timezone
: : information into files that can be examined by the appropriate
: : library routines would also be a good way to identify which minutes
: : get 61 (or 59) seconds. As with the timezone data, the leap second
: : table would have to be updated periodically to accommodate the latest
: : batch of administrative decrees on the subject.
:
: I can see this causing problems. If a program calculates some time
: in the future using a particular version of the leap second table,
: and then the table is updated then the calculation could be
: invalidated. One would need probably need to keep real-times
: (including leap seconds) separate from calendar-times (excluding
: leap seconds) and be careful about which one is working with.
But this is no different than the problem that already exists now
with ever-changing Daylight Savings Time rules! Any representation
of a future time (say, Mon May 5 15:51:31 BST 1997) can only be
assuming that the currently-understood DST rules will continue to
apply at the future date. As various governments continually change
their rules, the chosen time-point's representation may change.
Remember that UNIX systems measure time primarily in terms of time_t
values, which are the number of seconds since an arbitrary epoch.
Strings such as those produced and used by commands like date(1) and
cron(1) are only *representations* of underlying time_t values.
----------------------------------------------------------------------
Paul Schlyter
In article <4mjdof$4...@presence.lglobal.com>,
Matthew Francey <m...@presence.lglobal.com> wrote:
> pau...@electra.saaf.se (Paul Schlyter) wrote:
>
>>I would suggest that the requirement "the time is in UTC" is dropped
>>and replaced by "the time is in UT2".
>
> First of all, lets be totally clear from the start: leap seconds are a
> *user interface* issue. They only exist to maintain some a lock
> between our best time-pieces and the wobbly rotation of the Earth and the
> sense of "time" the creatures that happen to inhabit it. Like us. And
> (do I have to say it?), user interface crap doesn't belong in operating
> system kernels.
>
> Ok.
kernel task - it belongs to the device driver of the timer device. The
kernel just shuffles on the time to whoever requests it.
> The "problem" with UTC not existing in 1970 is pedantic -- like, who cares?
> If it is such a big deal, then I reckon that the use of the "Julian Day" be
> deemed equally bogus, since the Julian calendar simply did not exist
> in 4713BC.
weren't defined back then, but they're defined NOW! UTC is different:
even today it's not defined prior to 1972!
> So, no (or maybe I will yell it: NO!), the time_t should not be in UT2.
> The reason is that *all* implementations of the time_t is that of a
> continuously increasing counter. One click per second. So when 1996
> rolled in, I am totally confident that not one single "POSIX compliant"
> (assuming such a thing exists) computer system anywhere halted its counter
> for a single second, in due respect to Ye Olde POSIX Standard, with maybe
> a touch of reverence for the Leap Second itself.
relative to UTC, whenever there's a leap second in UTC. But I'm positive
some system administrator later sets it back to the real UTC -- what you
then really have is some approximation to UT2, plus/minus one second.
Who not formalize something that's already common practice?
> So if any redefinitions are to be made, I'd say it would be more appropriate
> to redefine time_t to be in TDT (or, better yet, lets think ahead: TDB).
immediately. TDT/TDB are only available after some delay, i.e. when
the astrometric positions determining this time scale (the most accurate
ones are of the moons position) have been reduced, which may be anything
from several days to several months after the fact....
> Looking at my copy of the POSIX spec [ya I know: get a life :-/], and the
> equation they give, this "fits" alot better. And we do not surrender the
> fundamental notion that the ticks of the time_t are real, honest-to-god
> hard "seconds" as experienced by the computer -- not the squishy,
> variable-length seconds of UT2.
back the system clock one second after a leap second has occurred.
> That in hand, we proceed to add, or modify, an entry point that can provide
> the current value of delta-T, delta-UTC, etc. And then move on to modify
> ctime(), localtime(), etc, to use this information to present the time
> in whatever format the caller wishes. Where such transformations belong.
Matthew Francey
pau...@electra.saaf.se (Paul Schlyter) wrote:
>Sure -- but the generation of the timer count isn't an operating system
>kernel task - it belongs to the device driver of the timer device. The
>kernel just shuffles on the time to whoever requests it.
This is one way you can think of it -- but in most kernels, I suspect,
The Time is run off a timer interrupt, and the time() system call is
nothing but a simple copy. The only operating system that matters :),
Linux, does as much.
For the lucky few who have atomic clocks in their basement, or are cheating
and using GPS (ie, stealing time from the US military), a driver
of some sort may be useful. But it would be wise that any such driver
return TDT, or TAI, or something sensible. Encoding calendars into
drivers, or kernels, is very silly. Something we have come to expect from
Microsoft -- UNIX people ought to, and by-and-large do, have more sense.
(The POSIX committee re: time notwidthstanding).
>This comparison is not valid. Julian Day numbers, as well as B.C. years,
>weren't defined back then, but they're defined NOW! UTC is different:
>even today it's not defined prior to 1972!
???
Argh! I can't remember the name of the guy that "invented" this idea.
(Actually, the Mayan's came up with it centuries earlier, but whatever).
But whoever it was, back in the 1500's(?), rather than concern himself
with the problem that the Julian calendar -- or likely any useful
calendar -- didn't exist in 4713BC, he just up and propogated a known
calendar way back into the past. And why not? His intent wasn't to give
meaning to "April 13, 3984BC". Just to define a count of "days", and
make sure in most cases, the number is positive.
If the lack of UTC before 1972 is a big deal, the answer is simple: you
just define that at 1972 Jan 1 00:00:00 UTC, the value of time_t
is <whatever>. But this is just another way of propogating UTC back
before 1972.
The POSIX spec, by the way, does exactly this. Unfortunately, rather than
1972, some random date in 1986 is used.
>Here you're saying that all POSIX compliant clocks gains one second
>relative to UTC, whenever there's a leap second in UTC. But I'm positive
>some system administrator later sets it back to the real UTC -- what you
>then really have is some approximation to UT2, plus/minus one second.
It is undeniable that some system-administrator input is required. But
this is true UTC or TDT. With UTC, the poor guy has to reset the time 1
second when a leap second occurs. After the fact. With a TDT definition,
she will have to update the /etc/leapseconds file and re-run 'zic'. But
the nice thing with this option is that it can be done *before* the fact.
And, even nicer, the fundamental time-scale is left untouched, ever
ticking away.
>Not a good suggestion! TAI is much better since it's available
>immediately. TDT/TDB are only available after some delay
But TDT = TAI + 32.184s.
>You get variable length seconds anyway when the system administrators set
>back the system clock one second after a leap second has occurred.
Well, as I've pointed out, we have the technology, by simply running a sed
script over the POSIX spec:
s/UTC/TDT/
s/Universal Coordinated Time/Terrestrial Dynamical Time/
...
to "define away" this problem. Anyone who is running the Olson/Harris
TZ code, and is using a leapseconds file, has more or less done exactly
this. Technically, not a POSIX compliant system. But who wants to
comply with a flawed specification?
Stephen Baynes
Bob Goudreau (goud...@dg-rtp.dg.com) wrote:
: In article <Dqrq7...@ukpsshp1.serigate.philips.nl>,
: bay...@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
Yes and no. In theory you are correct, but you assume that all existing
programs that do callender time/date arithmetic do it on a struct tm
rather than a time_t (which any ISO C conforming program would do), but
I suspect there are lots of programs that do arithmetic on time_t and
expect the result to be predictable in calender time. For example adding
60 to increase the time by one minute (so 23:59:32 => 00:00:32 )
Guy Harris
Matthew Francey <m...@presence.lglobal.com> wrote:
>Anyone who is running the Olson/Harris TZ code...
"Olson code", please. Arthur Olson was the original implementor; I was
just one of many who subsequently contributed to the code - Robert Elz,
Bradley White (who did the leap second stuff), Paul Eggert, etc. also
contributed to the code (and many many others contributed to the data
files). See the "README" file in the "tzcode" part of the package.
Paul Eggert
pau...@electra.saaf.se (Paul Schlyter) writes:
> Paul Eggert writes:...
> > As far as I can tell, it would be valid for a Posix implementation of
> > difftime to account for leap seconds.
> It would be impossible to do generally.
``Impossible'' is pretty strong. Posix doesn't require time_t to be an
integral type. If time_t was a float type, you could assign a time_t
value of X+0.5 to the leap second, where X is the previous second.
difftime(X+0.5, X) would yield 1, since difftime would know about leap seconds.
I'm not saying that it would be a good idea to do it this way, just
that it's possible.
>I would suggest that the requirement "the time is in UTC" is dropped
>and replaced by "the time is in UT2".
An interesting suggestion, but it's too late to make this change.
More likely the Posix committees will add new facilities to have proper timers.
I hope they do it better this time around. (It would be nice if they
would allow an implementation to supply a UT2-based clock, for example.)
Paul Eggert
m...@presence.lglobal.com (Matthew Francey) writes:
> The "problem" with UTC not existing in 1970 is pedantic -- like, who cares?
Perhaps; but if you're writing a standard you should make it tight
enough to satisfy people who need accurate time.
For example, the Posix spec could be rewritten to have an origin that
is a valid UTC time, and times before UTC existed (which have less
practical importance) could be some other approximation which is
historically valid far back into the past. Some people do care about
this sort of thing -- and it's not just astronomers.
> when 1996 rolled in, I am totally confident that not one single
> "POSIX compliant" (assuming such a thing exists) computer system
> anywhere halted its counter for a single second
Your confidence is unwarranted. See comp.protocols.time.ntp, for example.
Paul Eggert
m...@presence.lglobal.com (Matthew Francey) writes:
> If the lack of UTC before 1972 is a big deal, the answer is simple: you
> just define that at 1972 Jan 1 00:00:00 UTC, the value of time_t
> is <whatever>....
> The POSIX spec, by the way, does exactly this. Unfortunately, rather than
> 1972, some random date in 1986 is used.
Which Posix spec are you referring to? Posix 1003.1-1990 section
2.2.2.24 page 13 lines 153-154 defines the Epoch to be ``The time 0
hours, 0 minutes, 0 seconds, January 1, 1970, Coordinated Universal
Time''. As far as I know this error hasn't been corrected in later
editions.
Bob Goudreau
Matthew Francey (m...@presence.lglobal.com) wrote:
: If the lack of UTC before 1972 is a big deal, the answer is simple: you
: just define that at 1972 Jan 1 00:00:00 UTC, the value of time_t
: is <whatever>. But this is just another way of propogating UTC back
: before 1972.
: The POSIX spec, by the way, does exactly this. Unfortunately, rather than
: 1972, some random date in 1986 is used.
References, please? I don't see anything in any revision of the
POSIX.1 spec that uses a date in 1986 for an anchor. But, section
2.2.2.24 of POSIX.1-1990 defines the Epoch as:
The time 0 hours, 0 minutes, 0 seconds, January 1, 1970,
Coordinated Universal Time.
Matthew Francey
egg...@twinsun.com (Paul Eggert) wrote:
>Which Posix spec are you referring to? Posix 1003.1-1990 section
The same one:
"That is, it is important that all conforming systems
interpret '536457899 seconds since the Epoch' as
59 seconds, 59 minutes, 23 hours 31 December 1986 [...]"
(page 200, lines 628-629). This page, btw, is rather buggy. The
correct intent is there; just that whoever wrote it was obviously
confused over what leap seconds really are ...
-mdf
Paul Schlyter
In article <4mqv83$t...@white.twinsun.com>,
Paul Eggert <egg...@twinsun.com> wrote:
> pau...@electra.saaf.se (Paul Schlyter) writes:
>
>> Paul Eggert writes:...
>>> As far as I can tell, it would be valid for a Posix implementation of
>>> difftime to account for leap seconds.
>> It would be impossible to do generally.
>
> ``Impossible'' is pretty strong. Posix doesn't require time_t to be an
> integral type. If time_t was a float type, you could assign a time_t
> value of X+0.5 to the leap second, where X is the previous second.
> difftime(X+0.5, X) would yield 1, since difftime would know about leap
> seconds.
>
> I'm not saying that it would be a good idea to do it this way, just
> that it's possible.
remotely likely that there would be some implementation where time_t
was a float type which still only received integer values (except when
leap seconds were supposed to be marjed, as you suggest)? If I was to
implement time_t as a float type, I would surely use the float to yield
a considerably better time resolution than one second.
Paul Eggert
m...@presence.lglobal.com (Matthew Francey) writes:
> egg...@twinsun.com (Paul Eggert) wrote:
> > Which Posix spec are you referring to? Posix 1003.1-1990 section
>
> The same one:
> "That is, it is important that all conforming systems
> interpret '536457899 seconds since the Epoch' as
> 59 seconds, 59 minutes, 23 hours 31 December 1986 [...]"
> (page 200, lines 628-629).
That quote is from Annex B, which is not a normative part of the standard --
it is merely informative. It is commentary designed to make it easier
to understand the intent of the standard. `536457899' is merely an example.
See the Introduction, page x, lines 46-49, for a definition of ``informative''.
The relevant normative part of the standard is section 2.2.2.24;
this section refers to the (nonexistent) time 1970-01-01 00:00:00 UTC.
This is the part of the standard that is incorrect and needs fixing.
I think the intent of the standard is clear for UTC times;
what's not clear is what to do for times before UTC was established.
Chris Carrier
What is the current difference between UTC and TAI, with UTC and TDT 62.184
seconds apart? (as they are now).
Joe Seigh
Yes, but this is all rather a moot point since they keep moving the epoch. It's
not 1970-01-01 00:00:00 whatever but 1970-01-01 00:00:20. In fact, if we wait
until enough leap seconds have been added the epoch really will be when UTC was
defined to be in effect.
I used to think that adjusting the epoch to compensate for the buggy timestamp
conversion routines was bogus, but now I think it's rather ingenius. Say you
want the time_t value for 5 days from now. You can use "time() + 5*24*60*60"
and it will work because if a leap second did occur between then and now the
epoch will be adjusted to make it work. That's totally fabulous. No more
worrying about leap seconds. Pretend they don't exist.
In fact, I think we should extend that technique to leap days. Just add 365
days to get 1 year from now and epoch adjustment will take care of the rest if
need be. No more dealing with leap year calculations.
Ok. Ok. So it won't work one day every four years or so. But if we turned off
all the computers on that day...
Joe Seigh se...@bose.com
Guy Harris
["sci.astro" removed; this part of the thread isn't relevant to it.]
egg...@twinsun.com (Paul Eggert) wrote:
>Which Posix spec are you referring to? Posix 1003.1-1990 section
Matthew Francey <m...@presence.lglobal.com> wrote:
>The same one:
>
> "That is, it is important that all conforming systems
> interpret '536457899 seconds since the Epoch' as
> 59 seconds, 59 minutes, 23 hours 31 December 1986 [...]"
>
>(page 200, lines 628-629). This page, btw, is rather buggy.
It's also not part of the POSIX spec.
It's part of the *Rationale* for the POSIX spec. It's just an
*example*.
jbe...@gate.net
How dare anyone question the Time-god's leap seconds! <g>.
jEFF
Paul Schlyter
In article <4mujjk$f9i$2...@mhadf.production.compuserve.com>,
Chris Carrier <72157...@CompuServe.COM> wrote:
> What is the current difference between UTC and TAI, with UTC and TDT 62.184
> seconds apart? (as they are now).
Starting at TAI-UTC TDT-UT UT-UTC
1972-01-01 +10 +42.23 -0.05
1972-07-01 +11 +42.80 +0.38
1973-01-01 +12 +43.37 +0.81
1973-07-01 " +43.93 +0.25
1974-01-01 +13 +44.49 +0.69
1974-07-01 " +44.99 +0.19
1975-01-01 +14 +45.48 +0.70
1975-07-01 " +45.97 +0.21
1976-01-01 +15 +46.46 +0.72
1976-07-01 " +46.99 +0.19
1977-01-01 +16 +47.52 +0.66
1977-07-01 " +48.03 +0.15
1978-01-01 +17 +48.53 +0.65
1978-07-01 " +49.06 +0.12
1979-01-01 +18 +49.59 +0.59
1979-07-01 " +50.07 +0.11
1980-01-01 +19 +50.54 +0.64
1980-07-01 " +50.96 +0.22
1981-01-01 " +51.38 -0.20
1981-07-01 +20 +51.78 +0.40
1982-01-01 " +52.17 +0.01
1982-07-01 +21 +52.57 +0.61
1983-01-01 " +52.96 +0.22
1983-07-01 +22 +53.38 +0.80
1984-01-01 " +53.79 +0.39
1984-07-01 " +54.07 +0.11
1985-01-01 " +54.34 -0.16
1985-07-01 +23 +54.61 +0.57
1986-01-01 " +54.87 +0.31
1986-07-01 " +55.10 +0.08
1987-01-01 " +55.32 -0.14
1987-07-01 " +55.57 -0.39
1988-01-01 +24 +55.82 +0.36
1988-07-01 " +56.06 +0.12
1989-01-01 " +56.30 -0.12
1989-07-01 " +56.58 -0.40
1990-01-01 +25 +56.86 +0.32
1990-07-01 " +57.22 -0.04
1991-01-01 +26 +57.57 +0.61
1991-07-01 " +57.94 +0.24
1992-01-01 " +58.31 -0.13
1992-07-01 +27 +58.72 +0.46
1993-01-01 " +59.12 +0.06
1993-07-01 +28 +59.55 +0.63
1994-01-01 " +59.98 +0.20
1994-07-01 +29 +60.3 +0.9
1995-01-01 " +60.6 +0.6
1995-07-01 " +60.9 +0.3
1996-01-01 +30 +61.2 +1.0
1996-07-01 " +61.5 +0.7
1997-01-01 " +61.9 +0.3
For the latest status concerning leap seconds in UTC, send e-mail to
ads...@tycho.usno.navy.mil with a Subject: line of 'leap' and no
text. You will receive in reply a list of past and provisional future
leap seconds.
Paul Schlyter
In article <1996May1...@bose.com>, Joe Seigh <se...@bose.com> wrote:
>> The relevant normative part of the standard is section 2.2.2.24;
>> this section refers to the (nonexistent) time 1970-01-01 00:00:00 UTC.
>> This is the part of the standard that is incorrect and needs fixing.
>>
>> I think the intent of the standard is clear for UTC times;
>> what's not clear is what to do for times before UTC was established.
>
> Yes, but this is all rather a moot point since they keep moving the epoch.
> It's not 1970-01-01 00:00:00 whatever but 1970-01-01 00:00:20. In fact,
> if we wait until enough leap seconds have been added the epoch really
> will be when UTC was defined to be in effect.
Bill Owen
In article <4mujjk$f9i$2...@mhadf.production.compuserve.com>, Chris Carrier <72157...@CompuServe.COM> writes:
> What is the current difference between UTC and TAI, with UTC and TDT 62.184
> seconds apart? (as they are now).
>
32 seconds. TAI is 32.184 seconds behind TDT.
-- Bill Owen, w...@wansor.jpl.nasa.gov
Bill Owen
In article <4n7l8u$c...@netline-fddi.jpl.nasa.gov>, I wrote:
> In article <4mujjk$f9i$2...@mhadf.production.compuserve.com>, Chris Carrier <72157...@CompuServe.COM> writes:
> > What is the current difference between UTC and TAI, with UTC and TDT 62.184
> > seconds apart? (as they are now).
> >
>
> 32 seconds. TAI is 32.184 seconds behind TDT.
And maybe I oughta go back to second grade, or at least wake up on Monday
mornings before I post! 62.184 - 32.184 = 30.
-- Bill Owen, w...@wansor.jpl.nasa.gov
Tye McQueen
bay...@ukpsshp1.serigate.philips.nl (Stephen Baynes) writes:
) I can see this causing problems. If a program calculates some time in the
) future using a particular version of the leap second table, and then the
) table is updated then the calculation could be invalidated. One would need
) probably need to keep real-times(including leap seconds) separate from
) calendar-times(excluding leap seconds) and be careful about which one is
) working with.
That enhancement needs to be made anyway to solve the problem
of programs that calculate durations making incorrect measurements
when the Unix time is adjusted.
A sample of a quick way to do this with backward compatibility is:
Add a new system call, uptime(2), that returns the number
of clock ticks since the system booted [or seconds and clock
ticks, whatever].
Add a kernel variable, boottime, which stores the difference
between the values that should be returned by uptime(2) verses
time(2) [or gettimeofday(2/3), whatever]. This value would
start out as the value from time(2) when the system booted and
would rarely change.
Change sdate(2) [and settimeofday(2/3)] [and therefore date(1)]
so that it just updates the boottime variable.
Over time, change programs that compute durations from computing
the difference between values returns by time(2) to computing
the difference between values returns by uptime(2).
I would think some Unixes would have separated the time of day
clock from the system real-time clock by now, but I'm not aware of
any.
I'd probably have NTP daemons mess with boottime and leave the
clock tick counter alone. I love running "traceroute" on my
server that is running NTP and watch the "time tunnelling"
response packets that arrive _before_ the query packet is sent.
Long durations would be calculated with a little less accuracy,
but the gain in consistancy is probably worth that.
--
Tye McQueen t...@metronet.com || t...@thingy.usu.edu
Nothing is obvious unless you are overlooking something
http://www.metronet.com/~tye/ (scripts, links, nothing fancy)
Jeffrey W Percival
Paul Schlyter wrote:
> For the latest status concerning leap seconds in UTC, send e-mail to
> ads...@tycho.usno.navy.mil with a Subject: line of 'leap' and no
> text. You will receive in reply a list of past and provisional future
> leap seconds.
I just tried this e-mail address, and it returned an incorrect response
(it did not include the most recent leap second, at the start of this
year). How long does it typically take this service to reflect the
most recent activity?
---
Jeffrey W Percival
Space Astronomy Laboratory, University of Wisconsin - Madison
1150 University Ave, Madison, WI 53706 USA
(608)262-8686 j...@sal.wisc.edu http://www.sal.wisc.edu/~jwp
Paul Schlyter
In article <3198A4...@sal.wisc.edu>,
Jeffrey W Percival <j...@sal.wisc.edu> wrote:
> Paul Schlyter wrote:
>
>> For the latest status concerning leap seconds in UTC, send e-mail to
>> ads...@tycho.usno.navy.mil with a Subject: line of 'leap' and no
>> text. You will receive in reply a list of past and provisional future
>> leap seconds.
>
> I just tried this e-mail address, and it returned an incorrect response
> (it did not include the most recent leap second, at the start of this
> year). How long does it typically take this service to reflect the
> most recent activity?
and then added it to my text. Why don't you direct your question
to the postmaster at that site?
Joe Seigh
Reposting this. The original seems to have gotten lost.
In article <1996May1...@bose.com>, I wrote :
|> Of course, there are worse things in unix, like no time zone
|> indicators in the /etc/dumpdates file. You _have_ been making sure
|> those file systems have been quiesced for an hour after you dumped
|> them, haven't you?
Hmm... Maybe you're all off the hook on this one. I though I had sort
of investigated this one once before. mktime() even returns the
earlier of the two possible time_t values for the one hour of the year
that ambiguity even exists, the alternate time zone no less.
However, strptime() really is broken, which is why I have been a
little leery of timestamps without timezone indicators. It's setting
tm_isdst one higher than it should. Decrement tm_isdst by one before
you call mktime() and it seems to work better.
But it doesn't appear to be the case that dump/restore is calling
strptime(). If it is, it is correcting tm_isdst.
--
Joe Seigh se...@bose.com