asctime.c

[Paul Eggert]

"Clive D.W. Feather" <clive at demon.net> writes:

> A case would have to be made for this.

The case is pretty simple:

 * In practice more programs rely on the exactly-26-byte behavior,
   (which is still documented in many manuals) than in the
   standard-mandated behavior.

 * Many popular implentations fail to conform to the standard for
   years less than 1000.  This includes the current versions of
   Solaris and HP-UX.  No doubt there are others.

>> Can't we easily fix things by changing the standard to say that it's
>> implementation-specified as to whether the format uses %d or %4d for
>> the year?
>
> Actually %.4d would be better.

Wouldn't that print the year -9 as "-0009"?  That would be bad, since
programs depend on exactly 26 bytes.

If you don't like %4d, then we would go even further and allow more
implementation freedom, e.g., allow implementations to use %.4d for
positive years and %.3d for negative.  Portable code couldn't rely on
the exact behavior when years are in that range, but it can't rely on
the behavior now anyway.  Personally, though, I still think "%d or
%4d" is simplest.

> I'm not saying this is a hopeless cause, because this *is* clearly a
> case where WG14/X3J11 messed up.

OK.  What's the next step, if we'd like to pursue this more formally?
How does one file a defect report against the C Standard these days?
I could file one, though I'd like to credit Robert Elz for lighting a
fire under this issue.

The real problem here isn't the exact format: it's that widespread
existing softare assumes the exactly-26-byte output, and the C
standard breaks this software.