I'm thinking that a way to reduce the amount of coding to take care of wide-ranging tm_year values is to have asctime rely on strftime to get a correct year string. Can anyone else think of problems with this approach? --ado
On Mon, Oct 11, 2004 at 03:19:44PM -0400, Olson, Arthur David (NIH/NCI) wrote:
I'm thinking that a way to reduce the amount of coding to take care of wide-ranging tm_year values is to have asctime rely on strftime to get a correct year string. Can anyone else think of problems with this approach?
A couple of annoying details crop up in trying to match a strftime() format against what the C standard says that asctime()'s format should be: 1. The standard says asctime()'s day-of-month should be "%3d". For in-range values this can be a strftime " %e", but for out-of-range values there's not a good alternative. 2. The standard uses "%d" for the year, but "%Y" zero-pads when the field width would otherwise be shorter than 4 characters. --Ken Pizzini
Ken Pizzini <"tz."@explicate.org> writes:
A couple of annoying details crop up in trying to match a strftime() format against what the C standard says that asctime()'s format should be:
More generally, the standard says that strftime can assume that the tm_* values are in "the normal range", i.e., that tm_mday, tm_hour, etc., follow the rules of the Gregorian calendar and standard clock. (For example, the behavior of strftime is undefined if tm_hour == 24.) asctime is not allowed to make all these assumptions, and therefore asctime cannot invoke a standard strftime and expect it to do the right thing with out-of-range values. One way out of this is to require tz's asctime to invoke tz's strftime (rather than some generic strftime), and to extend tz's strftime to have formats sufficient to implement tz's asctime. I considered doing this, but it was more work (and overall, more confusing) than simply duplicating the 10 lines or so of code in question.
participants (3)
-
Ken Pizzini -
Olson, Arthur David (NIH/NCI) -
Paul Eggert