Mail Archives: djgpp/2000/12/27/03:02:41
On Tue, 26 Dec 2000, Jason Green wrote:
> > > > But C99 defines about a dozen more conversion specifiers which aren't
> > > > supported by DJGPP right now. It would be nice to add them as well.
> > >
> > > I agree, but this all takes time. If %z is fixed now shouldn't it go
> > > in?
> >
> > I didn't say it shouldn't. But fixing %z alone doesn't sound like a big
> > win to me.
>
> Well I started this by trying to fix one user's problem... :-/
That's how things are with fixing the library: you start with
something simple, and then there's a whole lot more to be done.
Someone (tm) has got to do that ;-)
> --- src/libc/ansi/time/strftime.txh.orig Mon Aug 2 12:28:18 1999
> +++ src/libc/ansi/time/strftime.txh Sun Dec 24 11:01:52 2000
> @@ -149,6 +149,10 @@
>
> The timezone abbreviation (@code{EDT})
>
> +@item %z
> +
> +The time-zone as hour offset from UTC (@code{-0500})
> +
> @item %%
Thanks.
> > > BTW, if I fill a struct tm with values for 0/Jan/YYYY, then call
> > > mktime(), it should be modified to 31/Dec/(YYYY-1), right? This isn't
> > > happening.
> >
> > Please post a complete example.
>
> The program below prints:
>
> Mon, 00 Jan 2001
>
> Unless I am mistaken, it should print:
>
> Sun, 31 Dec 2000
Yes, the current version of mktime doesn't cope with tm_day <= 0 if
tm_mon is zero. Any positive tm_mon does work, I think. Thanks for
reporting this.
- Raw text -