Robert Elz said:
I agree with that, though I suspect my interpretation of "valid" might be different than yours. I'd prefer to always return a string that fits exactly in a 26 byte buffer, with the \n in buf[24] and \0 in buf[25], and every other character posit position occupied by exactly what is supposed to be there (the colons at known offsets, etc).
The problem is that the only specification for "exactly what is supposed to be there" is what's in the standard.
If that makes the output be "incorrect" when the input struct tm contains values (way) beyond those which asctime() was designed to handle, then that's just fine with me. Where we can handle the value, and retain the output format, we should however.
Assuming that all fields except the year are in range, then we have the following cases: * Years 1000 to 9999 and -999 to -100: everyone agrees. * Years before -999 or after 9999: undefined behaviour, so implementations can do what they want. * Years -99 to 999: the C standard says the string should be shorter, you say the string should contain extra spaces or zeroes. I don't believe that there has ever been a real expectation for that case. I don't know the history of the asctime() specification, but I suspect that it has more basis than your claim.
People expecting (or who should be expecting) to deal with arbitrary struct tm values - or in fact, just about any current code expecting to convert times into strings ought to be using strftime,
People expecting an exact format for the output should be using strftime. asctime() is a quick-and-dirty interface to produce something that can be output in a log file or similar. It's not intended to be an exact science. -- 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 | |