asctime.c

[Robert Elz]

    Date:        Thu, 22 Jul 2004 10:30:47 -0400
    From:        "Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov>
    Message-ID:  <75DDD376F2B6B546B722398AC161106C740265 at nihexchange2.nih.gov>

  | Code in "asctime" such as...

  | ...never returns NULL and never (when applied to a "struct tm" derived from
  | a 64-bit time_t) overflows a 26-character buffer passed to asctime.
  | It does lose time-of-day information in the distant past and distant future.

Please, don't do that, or anything like it.   Every byte in that 26 byte
buffer has a defined (very well known) meaning, and code that extracts
fields from the asctime output by simply knowing the byte offsets of the
relevant fields is (and has been for many years) very very common.
So is the fact that the buffer is exactly 26 bytes (25 data and the 
terminating 0).

Don't attempt to fix bugs in the interface of this function, or change it
any way at all - for years outside -999..9999 do whatever you like (a
NULL return is OK, I guess, though lots of code doesn't bother checking,
at least the least evil of several possible evils) - but just truncating
the year to the last 4 digits would do as well, just as long as those 4
byte locations are filled with the year number (code that just uses %ld
is wrong, as it won't properly use a 4 byte wide field - which isn't a
problem if we assume the value is never < 1900, of course, which old
code did, but will be a problem if you're going to handle years < 1000).

Sometime, someone, somewhere, can define a new function if they want
(probably they never will, since strftime() is a perfectly good replacement
for asctime for any new uses) and alter the output format.   But that
can't be asctime().

And note here, I don't care in the slightest what the standards say
for this - asctime and the format of that 26 character buffer is one
of the oldest, and most stable, infertaces in all of unix - since it
was invented, it has never altered, in any unix variant.   Fortunately
the standards makers also seem to understand this - which is why the
day & month names are always the English abbreviations, no matter
what the locale is, etc.

kre