In message <32DD304D.40D@Renault.FR>, Antoine Leca wrote:
I didn't change anything, but this raises a point: wouldn't it be better to pass a « time_t const *t » argument? This is for consistency with other library functions, and portability (particularly when time_t is a floating type).
This rises an interesting question: Why does the C library functions always access time_t values by constant pointers and not by simply copying the value??? I never understood this part of the C lib API. How is portability increased by not using a call-by-value here? If there is any good reason that this has been done in libc, then I'd of course also add it to my code. I already did it for consistency with the existing library functions, but I'd like to know why this is supposed to be the right thing to do.
¤ Comparing t with 0 doesn't take any sense (I know one system where ¤ (time_t)0 is J2000,0, so negative t are allowed before 2000-01-01 12:00:00Z
Ok, you are right. I just hope that the system you know does not encode 2000-01-01 11:59:59Z = (time_t) -1 as this value is reserved by the standard for error conditions.
¤ Basically, you can't trust strftime to output what you want if you ¤ don't set the locale to "C" before. ¤ I know this code is overkill in the vast majority of cases.
I just checked the standard again and it does not indicate that any of the conversion specifiers "%Y-%m-%d %H:%M:%S" depend on the locale. There ARE many conversion specifiers that depend on the locale, but not the above ones, so I understand that we do not have to switch to the "C" locale.
****** 8601.c if (prec > 0) { sprintf(buf, ".%09ld", nsec); buf += prec + 1; ****** 8601wrt.c if (prec > 0) { int i=9; while (i-->prec) nsec /= 10; sprintf(buf, ".%0*ld", prec, nsec); buf += prec + 1; ******
¤ I wrote this modification for avoiding a overflow of the buffer. ¤ You may consider it as unnecessary (but you then may consider ¤ issuing a warning in the man page).
I checked already that nsec is not out of range previously, so I think this additional check is redundant. Thanks for your good comments and also for those I received from others. I'll post the next revision here soon. Markus -- Markus G. Kuhn, Computer Science grad student, Purdue University, Indiana, USA -- email: kuhn@cs.purdue.edu