Paul Eggert said:
It looks like the people who turned that specification into C89 got it slightly wrong. But I doubt it's going to get changed now. 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.
This would allow both fixed-width and and strict C89 implementations.
This change could, in theory, break an existing program which relied on the present specification. In addition, it moves certain boundary cases from defined to undefined behaviour, which is generally seen as bad. A case would have to be made for this.
In practice, portable programs can't assume the C89 behavior now anyway.
For some value of "portable". There's "portable to all Standard C implementations" and "portable to both Standard and pre-Standard C". As a general rule, WG14 restricts itself to the former; the whole point of the process was to decide which of the latter should or should not be addressed. 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.
It looks like the best we'll get is to have HISTORICAL and STANDARDIZED versions, selected at compile time. Sorry, I don't follow this remark -- are you referring to the tz code, or to the standard itself?
The tz code. -- Clive D.W. Feather | Work: <clive@demon.net> | Tel: +44 20 8495 6138 Internet Expert | Home: <clive@davros.org> | Fax: +44 870 051 9937 Demon Internet | WWW: http://www.davros.org | Mobile: +44 7973 377646 Thus plc | |