This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Maintainer of timezone/zdump.c
- From: "Earl C. Ruby III" <earl at switchmanagement dot com>
- To: aj at suse dot de, libc-alpha at sources dot redhat dot com, tz at elsie dot nci dot nih dot gov
- Date: Thu, 19 May 2005 16:28:40 -0700
- Subject: Maintainer of timezone/zdump.c
- Reply-to: earl at switchmanagement dot com
I am trying to locate the maintainer of the timezone/zdump.c program.
According to the RPM that comes with SuSE, zdump is part of
glibc-2.3.3-118.src.rpm. I found your e-mail addresses attached to that RPM
or to mailing list messages indicating that you worked on zdump.c.
I am running several dozen SuSE Linux systems and all of them show the same
(incorrect) results when zdump is run for an "Etc/UTC+X" timezone. The same
incorrect results show up for "Etc/UTC-X", "UTC+X", "UTC-X", "Etc/GMT+X",
"Etc/GMT-X", "GMT+X" and "GMT-X" timezones.
Specifically, there's a sign error. For instance, Guam's timezone is ChST,
which is the same as UTC+10. If I run zdump for Guam I get the correct
results:
> /usr/sbin/zdump -v -c 2006 Pacific/Guam
Pacific/Guam Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 06:45:52 1901 ChST
isdst=0 gmtoff=36000
Pacific/Guam Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 06:45:52 1901 ChST
isdst=0 gmtoff=36000
Pacific/Guam Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 13:14:07 2038 ChST
isdst=0 gmtoff=36000
Pacific/Guam Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 13:14:07 2038 ChST
isdst=0 gmtoff=36000
The GMT offset for Guam is 36000 seconds (+10 hours * 3600 seconds per hour).
If you add 36000 seconds to "Sat Dec 14 20:45:52 1901 UTC" you get "Sun Dec
15 06:45:52 1901 ChST". That's all good.
If I run zdump for Etc/UTC+10 I get :
> /usr/sbin/zdump -v -c 2006 Etc/UTC+10
Etc/UTC+10 Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 10:45:52 1901 Etc/UTC
isdst=0 gmtoff=-36000
Etc/UTC+10 Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 10:45:52 1901 Etc/UTC
isdst=0 gmtoff=-36000
Etc/UTC+10 Mon Jan 18 03:14:07 2038 UTC = Sun Jan 17 17:14:07 2038 Etc/UTC
isdst=0 gmtoff=-36000
Etc/UTC+10 Tue Jan 19 03:14:07 2038 UTC = Mon Jan 18 17:14:07 2038 Etc/UTC
isdst=0 gmtoff=-36000
In this case, zdump shows that the offset is -36000 seconds, which is
incorrect.
I personally live in California, which is currently on Pacific Daylight Time,
or UTC-7. If I check zdump for "America/Los_Angeles" it shows the current
offset as -25200 seconds, which is correct:
> /usr/sbin/zdump -v -c 2006 America/Los_Angeles
America/Los_Angeles Sun Apr 3 10:00:00 2005 UTC = Sun Apr 3 03:00:00 2005
PDT isdst=1 gmtoff=-25200
However, if I ask for the offset for UTC-7, I get +25200 seconds, which is not
correct:
> /usr/sbin/zdump -v -c 2006 UTC-7
UTC-7 Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:45:52 1901 UTC isdst=0
gmtoff=25200
UTC-7 Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:45:52 1901 UTC isdst=0
gmtoff=25200
UTC-7 Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 10:14:07 2038 UTC isdst=0
gmtoff=25200
UTC-7 Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 10:14:07 2038 UTC isdst=0
gmtoff=25200
> /usr/sbin/zdump -v -c 2006 Etc/UTC-7
Etc/UTC-7 Fri Dec 13 20:45:52 1901 UTC = Sat Dec 14 03:45:52 1901 Etc/UTC
isdst=0 gmtoff=25200
Etc/UTC-7 Sat Dec 14 20:45:52 1901 UTC = Sun Dec 15 03:45:52 1901 Etc/UTC
isdst=0 gmtoff=25200
Etc/UTC-7 Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 10:14:07 2038 Etc/UTC
isdst=0 gmtoff=25200
Etc/UTC-7 Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 10:14:07 2038 Etc/UTC
isdst=0 gmtoff=25200
If you are the current maintainer of this program, or know who is, could you
help me out here? I've written a set of Perl timezone conversion routines
which pull data from zdump. I've added a patch to my software which works
around this problem with zdump, but I feel that zdump itself should be fixed
to deal with this.
--
Earl C. Ruby III
Senior Systems Engineer / Developer
Switch Management