🚀 go-pugleaf

In article <12453@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
[attribution stolen by Mr. Harris]:
>>It doesn't explicitly say "leap years are respected" either!  It doesn't
>>have to.  Leap seconds, like leap years, are now built into our calendar;

I agree with this.  (Personal opinion only.)

>Yes, but they're not built into most UNIX systems, whence "localtime()"
>and company came, so:

I agree with this too.  Therefore, under most UNIX systems, here is one more
bit of effort that must be undertaken by developers of ANSI/ISO C language
standard conforming implementations.  (Except for an ugly escape, see below.)

>>the standard would have to explicitly say if they *weren't* respected.

I agree with this too.  (Personal opinion only.)

Unfortunately, the C language standard says that the local time zone is
implementation defined.  Therefore lazy implementors can define their local
time zone as being a few seconds off of correct time.  They probably can't
say exactly how many seconds off, but they probably can say how to compute
how many seconds off, instructing the user to find a database elsewhere.

The time() function is defined as returning the implementation's best
approximation to the current calendar time.  On some hardware, the best
approximation is "20th century".  (I can't even say "Heisei era" because
many machines without timers were built in the Showa era, :-) but true.)

The gmtime() must accurately convert every possible valid time_t value to
a UTC time or else return a null pointer.  An implementation can be defined
as saying that UTC is not available, always returning a null pointer.

So, a very ugly implementation can be defined and conform without knowing
about leap seconds.

HOWEVER:  if the implementation's gmtime() ever returns a non-null pointer,
then the conversion must be accurate.  I'm not sure if a clever programmer
can write a conforming (to that implementation's documented definitions)
program that will find out enough about the implementation's declaration of
time_t, call gmtime() twice, and find that two times which are supposed to
be 2 seconds apart get reported as 1 second apart.  Or call gmtime() once
and find that the wrong year is returned :-).  If it can be done, then such
an implementation is proved non-conforming.

The standard says that the local time zone is implementation defined but
does not say that time_t is implementation defined.  So in some cases, the
programmer might have to be cleverer than me, or it might not be possible.
But I'm sure I'm capable of proving some implementations non-conforming.

>Or, in other words, you can assert all you want that the ANSI C standard
>requires that leap seconds be honored - and, believe me, I'd be
>overjoyed if it did, as it'd have whipped the POSIX folks into line -

ANSI section 4.12.3.3 does not say "an approximation" of UTC.

>(Hence the redirection to "comp.std.c".  I suspect it won't provoke a ruling,

Of course.  You have to send a business-like letter by snail mail to get that.

>but it might provoke somebody with more CFT than I to write in

Unfortunately, standard C does not provide CFT  :-)
--
Norman Diamond       diamond@jit081.enet.dec.com
If this were the company's opinion, I wouldn't be allowed to post it.
"Yeah -- bad wiring.  That was probably it.  Very bad."