Re: [Bug-gnulib] Re: CVS trunk testing results (PowerBook G4 MacOS X - 10.2.8)

[Paul Eggert]

"Mark D. Baushke" <address@hidden> writes:

>> First, does TZ="UTC" even work at all?
>
> Yes.

Did you observe that merely by example, or is there some deeper reason
why you know that it works?  For example, is TZ="UTC" documented to
work?  (Is the implementation's source code available, and if so where?)

Do you observe the same bug if TZ="UTC0" instead?

> When TZ is not defined, the default system timze zone is "-0800" which
> prints PST.

That could be due to a lot of things.  For example, on my host (Debian
stable), the C library consults /etc/zoneinfo, which on my host is a
symlink to /usr/share/zoneinfo/America/Los_Angeles, which means that
if TZ is not set then it behaves as if TZ were set to
"America/Los_Angeles".  This is a pretty common setup, and I'd expect
Mac OS X to be similar, except that I'm worried that they've gone off
and done their own thing in the tz area.  (Note that TZ="-0800" is
probably not allowed.)

> $ ./getdate
> Enter date, or blank line to exit.
>         > 1970-01-01 2:00:00 -0400
> 1970-01-01 06:00:00.000000000

Wait a second -- that's the correct answer.  Why are you not observing
the bug here?  What distinguishes your environment from the buggy one?

Perhaps you have to submit exactly the same test cases in the same order,
because mktime and/or getdate has internal state?

>         > "1970-01-01 2:00:00 +0400
> Bad format - couldn't convert.

That's correct, because you put a '"' at the start.  If you omit the
'"' I'd expect the output to be "1969-12-31 14:00:00.000000000".
Your GDB sessions also are reporting the correct answer.

> Hmmm... it does not seem to have stopped at mktime along the way... :-(

On your host you have to put a breakpoint on the rpl_mktime function
instead of the mktime function.  But if you're not observing the bug
the point is somewhat moot.