asctime.c

Clive D.W. Feather clive at demon.net
Thu Jul 29 14:52:46 UTC 2004


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 at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the tz mailing list