C Code for draft-newman-datetime-00.txt

[Markus G. Kuhn]

In message <32DD304D.40D at 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 at cs.purdue.edu