"Clive D.W. Feather" <clive@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.