asctime.c

[Robert Elz]

    Date:        Mon, 2 Aug 2004 09:16:35 +0100
    From:        "Clive D.W. Feather" <clive at demon.net>
    Message-ID:  <20040802081635.GD7224 at finch-staff-1.thus.net>

  | Actually %.4d would be better.

You'd prefer years with leading zeroes?   Why?   Year 0103 looks like
someone might be playing with octal base output to me ... -- on the other
hand, everyone is used to leading zeroes on minutes and seconds, as they
come after the ':' usually - the 0 isn't seen as redundant, and in the
hours, the leading 0 generally implies that a 24 hour clock is being
used (except the time isn't late enough for it to be obvious, so we
have 1am or 1pm, but 01 hours.)

  | This change could, in theory, break an existing program which relied on the
  | present specification.

It could, but should there be any?   The mistake that was made here was
in standardising asctime/ctime at all when strftime was all that was needed.
The older functions clearly have a stupid interface (for any half modern
requirements) - the only reason we should be keeping them is for compatability
with old code.   There's no reason to do that if they're going to be
changed, even slightly, from the historical definitions.  And that
remains true no matter how much one may be considered to be "just handling
previously undefined cases".

  | For some value of "portable". There's "portable to all Standard C
  | implementations" and "portable to both Standard and pre-Standard C".

There's only one definition of "portable" that matters - if I code in
this particular way, can I distribute my code and assume that it will
work everywhere (here that means, everywhere there's a compiler that
claims to compile C code).

Technical arguments about who is right, what the implementation is
being compatible with, and all the rest simply don't matter.   If my
code fails on *any* implementations, it isn't portable.

If I want my code to be portable, it has to work on everything that
is able to compile it.

  | I'm not saying this is a hopeless cause, because this *is* clearly a case
  | where WG14/X3J11 messed up. But nobody has spotted this fact in 16 years
  | or longer, meaning it's not exactly been a major concern.

That's most likely because no-one has been dealing with years outside the
1900-2140 address block very much (given that's all a 32 bit time_t can
represent).   Regardless of the possibility to set tm_year to just about
anything, almost no-one does.   It has been the recent interest in handling
64 bit time_t's that raised this issue now.

kre