asctime.c

[Paul Eggert]

"Olson, Arthur David (NIH/NCI)" <olsona at dc37a.nci.nih.gov> writes:

> Is using "%-4ld" to print the year a happy medium?

You mean, print something like "999 " for the year, with trailing
spaces?  Sorry, no, that doesn't conform either.  If we're going to
fail to conform to the standard, we shouldn't mess around with
left-justification: it's even more confusing.

I agree with Robert Elz that "that code is broken. End of story" is
too harsh.  That is why I'm advocating that we continue to have
asctime always return a valid non-NULL string, even though the
standard doesn't require this.  This is a good thing -- we shouldn't
gratuitiously break common usage even if it's no longer conforming.

However, I'm not convinced by this example that it's worth departing
from the standard here.  Here's the example again:

  printf("The date is: %.24s today\n", asctime(tm));

This code does not work with arbitrary "tm" anyway, even on PDP-11
Unix Version 7 with 16-bit int and 32-bit timestamps.  This is because
the code will print garbage by truncating long years in some cases.
There is no escaping this: asctime can't squish years past 9999 or
before -999 into that string without either munging the traditional
format (which will break other common usage) or printing the wrong
year (which is simply incorrect).

Since this example is already broken for years after 9999 or before
-999, we needn't worry about the fact that conforming to the standard
will also break this code for years in the range -99 through 999.  If
the example's "tm" was derived from a 32-bit time_t a la traditional
Unix, there is no problem since the year will be at least 1901.  And
if "tm" was derived from a 64-bit time_t, or was constructed from
arbitrary data, the code is already broken.

So, let's just stick with the standard behavior (extended so that
asctime never returns NULL).  In practice, it won't break any
applications that aren't already broken.