🚀 go-pugleaf

Guy Harris writes:

> Well, as you redirected followups to "comp.lang.c", and just said "ANSI
> C time functions" in the header, you presumably want the ANSI C answer.
> 
> The ANSI C answer is, from 4.12.2.4 "The 'time' function":
> 
> 	   The "time" function determines the current calendar time. 
> 	The encoding of the value is unspecified.
> 
> So the answer to the question "Does 'time()' return GMT or UTC?" is
> "no".  I.e., it does not return GMT *or* UTC; it returns an
> uninterpretable cookie.
> 
> Now, if you want a better answer, you'd better ask for the UNIX/POSIX
> 1003.1 answer (which is why I am redirecting followups back *to*
> "comp.unix.programmer").

Well, there is more to say from an ANSI C perspective, so I've put
comp.lang.c back in the list.  Followups are not redirected anywhere;
I'm not sure where, if anywhere, this thread is now aiming for.
Actually, comp.lang.c is for all forms of C; comp.std.c is the correct
newsgroup for ANSI C; but I don't want to summarize the background
of the thread enough to put it in that newsgroup.

So, Guy quotes POSIX 1003.1 section 2.3:

> 	A Coordinated Universal Time name specified in
> 	terms of number of 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 \italic{seconds since the Epoch} according to the
> 	expression below.
> 
> 	   If year < 1970 or the value is negative, the relationship is
> 	undefined.  If year >= 1970 and the value is non-negative, 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

and the POSIX Rationale:

> 	The concept of leap seconds is added [to UTC] for precision; at the
> 	time this standard was published, 14 leap seconds had been added
> 	since January 1, 1970.  These 14 seconds are ignored to provide
> 	an easy and compatible method of computing time differences.

And he summarizes this thus:

> As I've read it, that amounts to "neither 'gmtime()', 'localtime()', nor
> 'mktime()' acknowledge the existence of leap seconds; they act as if no
> leap seconds ever occur".

With which I agree.  HOWEVER, the C standard differs!  Specifically,
in section 4.12.1 (ANSI numbering, 7.12.1 in ISO), in the definition
of a broken-down time, it says:

	int tm_sec; /* seconds after the minute -- [0,61] */

A footnote points out that the choice of 61 rather than 59 is to allow
for "as many as two leap seconds".  So the C standard clearly *is*
calling for leap seconds to be respected.  This is an outright conflict,
though not a serious one for most applications, I think.

What happens now?
-- 
Mark Brader			Summary of issue:  Fix FORTRAN-8x.
SoftQuad Inc., Toronto		Committee Response:  This proposal contains
utzoo!sq!msb				insurmountable technical errors.
msb@sq.com			-- X3J11 responses to 2nd public review

This article is in the public domain.