gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] s/GMT/UTC/


From: Phil Frost
Subject: Re: [Gnu-arch-users] s/GMT/UTC/
Date: Tue, 7 Sep 2004 11:52:35 -0400
User-agent: Mutt/1.5.6+20040722i

time_t is an integer. Leap seconds are irrelevant to time_t. Leap
seconds become relevant only when determining the natural date and time,
such as "Tue Sep  7 11:04:35 EDT 2004".

The date counter can be easilly corrected for leap seconds, and in fact,
it is. POSIX defines the unix epoch as a count of non-leap SI seconds.

POSIX complicates some things by asserting that time_t does not include
leap seconds; it also assumes that all years divisable by 4 are leap
years. Although this requires time libraries to implement a correction
for POSIX, POSIX is quite clear that time_t is based on the SI second,
not solar time.

Here are some exerpts from man pages:

"time returns the time since the Epoch (00:00:00 UTC, January 1, 1970),
measured in seconds." --time(2)

"The ctime(), gmtime() and localtime() functions all take an argument of
data type time_t which represents calendar time. When interpreted as an
absolute time value, it represents the number of seconds elapsed since
00:00:00 on January 1, 1970, Coordinated Universal Time (UTC)."
--ctime(2)

"Perform operations as if the TZ environment variable was set to the
string "UTC0", or its equivalent historical value of "GMT0"." --date(P)

Grepping my man pages finds 113 occurances of "UTC" and only 55 of
"GMT". Many of the GMT references are parenthetical as in date(P)
above, for example.

In another thread it was suggested that UTC does not allow times in the
future to be described. This is not true. UTC is by definition never
more than 0.9s in error of GMT; this is the purpose of leap seconds. In
fact, unless the earth's rotation is more important than the observed
rate of change in everything else on the Earth's surface, GMT does not
allow specification of time in the future either. Those who require
accurate future times measure in SI seconds from an epoch.

Given that POSIX defines times with an SI second, this is the
overwhelmingly common practice, and that not only computers but every
time service in the world uses UTC (the natural time based on SI
seconds), I see no reason the historical and inacurate "GMT" should be
prefered over "UTC".

On Tue, Sep 07, 2004 at 01:46:46PM +0200, Jan Hudec wrote:
> On Tue, Sep 07, 2004 at 02:00:17 +0100, Andrew Suffield wrote:
> > On Tue, Sep 07, 2004 at 08:14:29AM +1000, Zenaan Harkness wrote:
> > > UTC is the newer name for GMT (actually, technically I thik they're
> > > slightly different times, but anyway...).
> > 
> > UTC is basically the world trying to deny that timezones originate in
> > Greenwich by renaming it. Political correctness gone completely insane.
> 
> No, they are defined differently.
> (However, UT1 is what was called GMT before (and most people keep
> calling it GMT)).
> 
> > > My recommendation is to use UTC rather than GMT. It's more accurately
> > > defined.
> 
> Right. time_t excludes leap seconds, so it really tracks GMT.
> 
> But at any point in time, GMT and UTC differ by at most 0.9s, and since
> time_t precision is 1s, it can be considered the same.
> 
> UTC inserts leap seconds, so the date counter can't be easily converted
> to seconds. GMT on the other hand stretches the seconds, so the interval
> corresponding to some number of seconds is not defined.
> 
> The article at:
> http://www.ucolick.org/~sla/leapsecs/onlinebib.html
> contains some discussion of how POSIX time and NTP time should be viewed
> and concludes, that it's appropriate to consider them UT, that is GMT,
> rather than UTC.
> 
> Thus I would vote for NOT changing the timezone specification to UTC.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]