[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: [Bug-gnulib] Re: CVS trunk testing results (PowerBook G4 MacOS X - 10.2.8)
Date: Wed, 10 Nov 2004 12:57:43 -0800
User-agent: Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)

Derek Robert Price <address@hidden> writes:

> The getdate.y module is failing near the UNIX epoch on Mac OS X, but
> only when TZ=UTC.

First, does TZ="UTC" even work at all?  POSIX says that you have to
TZ="UTC0", and that the behavior of TZ="UTC" is undefined.  Most
implementations I'm familiar with (glibc, Olson, Solaris) treat
unknown time zones as if they were UTC, but if Mac OS X is using their
own implementation perhaps it screws up in some cases.  Your bug
report also talks about setting TZ="-0800" but this also has undefined

> For example, entering either "1970-01-01 2:00:00 -0400" or
> "1970-01-01 2:00:00 +0400" with TZ=UTC on OS X will yield the output
> "1970-01-01 02:00:00.000000000", which I would hazard is obviously
> incorrect for any single given local timezone.

Yes, you're right.  If the time zone offset is specified explicitly,
which is the case here, then TZ should be irrelevant.

> Has anyone heard of anything like this before?


> rereading of the complex getdate.y code hasn't given me any
> inspiration.

Is your implementation using Mac OS X mktime, or gnulib mktime?

What is the value of HAVE_TM_GMTOFF?  If it is 1 and if you are using
Mac OS X mktime, perhaps Mac OS X mktime is returning a bogus value in
the tm_gmtoff member when TZ="UTC".  That might explain the bug.  Can
you put a breakpoint on line 1285 of getdate.y ("if (pc.zones_seen)")
and single-step through each statement in the then-part of that if
statement, and tell us what value got assigned in each assignment?

Also, can you give us a trace of all calls to mktime, what the input
values were, and what the returned value and the resulting struct tm
was?  That might help us narrow it down.

For example, try reproducing the following GDB session and see where
your results diverge from mine.

Current directory is /tmp/
GNU gdb 2002-04-01-cvs
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) b main
Breakpoint 1 at 0x804b1e9: file getdate.y, line 1374.
(gdb) set env TZ UTC0
(gdb) r
Starting program: /tmp/getdate 
[New Thread 1024 (LWP 15596)]
[Switching to Thread 1024 (LWP 15596)]

Breakpoint 1, main (ac=1, av=0xbffffa24) at getdate.y:1374
(gdb) b getdate.y:1285
Breakpoint 2 at 0x804ad73: file getdate.y, line 1285.
(gdb) b mktime
Breakpoint 3 at 0x804bdf0: file mktime.c, line 480.
(gdb) c
Enter date, or blank line to exit.
        > 1970-01-01 2:00:00 -0400

Breakpoint 3, mktime (tp=0xbfffd910) at mktime.c:480
(gdb) p *tp
$1 = {tm_sec = 0, tm_min = 0, tm_hour = 2, tm_mday = 1, tm_mon = 0, tm_year = 
70, tm_wday = 1075069056, 
  tm_yday = 1074333038, tm_isdst = -1, tm_gmtoff = 1073821132, tm_zone = 
0xbffffa24 "\211.�."}
(gdb) fin
Run till exit from #0  mktime (tp=0xbfffd910) at mktime.c:480
0x0804ab49 in get_date (result=0xbfffd9ac, p=0xbfffd9b4 "1970-01-01 2:00:00 
-0400\n", now=0xbfffd838)
    at getdate.y:1237
Value returned is $2 = 7200
(gdb) p tm
$3 = {tm_sec = 0, tm_min = 0, tm_hour = 2, tm_mday = 1, tm_mon = 0, tm_year = 
70, tm_wday = 4, tm_yday = 0, 
  tm_isdst = 0, tm_gmtoff = 0, tm_zone = 0x804d1d0 "UTC"}
(gdb) c

Breakpoint 2, get_date (result=0xbfffd9ac, p=0xbfffd9b4 "1970-01-01 2:00:00 
-0400\n", now=0xbfffd838)
    at getdate.y:1285
(gdb) n
(gdb) n
(gdb) p delta
$4 = -14400
(gdb) n
(gdb) p delta
$5 = -14400
(gdb) n
(gdb) p t1
$6 = 21600
(gdb) n
(gdb) n
(gdb) p Start
$7 = 21600
(gdb) c
1970-01-01 06:00:00.000000000

reply via email to

[Prev in Thread] Current Thread [Next in Thread]