Date: Tue, 1 Jul 2003 08:30:13 -0700 (PDT) From: Barry Pederson <bp@barryp.org> To: freebsd-bugs@FreeBSD.org Subject: Re: bin/53899: mktime gives wrong result in Central timezone Message-ID: <200307011530.h61FUDAp053481@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/53899; it has been noted by GNATS.
From: Barry Pederson <bp@barryp.org>
To: Nick Triantos <nick@triantos.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: bin/53899: mktime gives wrong result in Central timezone
Date: Tue, 01 Jul 2003 10:29:00 -0500
Nick Triantos wrote:
> I found out the hard way that this is apparently not a bug, but a
> feature. On *BSD systems, for some weird reason, mktime() does not call
> localtime(). I had submitted a patch to fix this, but it got removed
> because there are apparently some applications that depend on this
> unusual behaviour.
>
> To work around the problem, call localtime() manually.
I'm not sure what this has to do with localtime(), and I have a hard time (no
pun intended) believing there are applications that depend specifically on
mktime() acting strangely for the US Central timezone, but giving results for
Eastern, Mountain, and Pacific that seem to make sense.
I've dug into this some more and have found there is a reason for Central
being different....
The files in /usr/src/share/zoneinfo describe timezones, including historical
information on when daylight savings changes took effect, going back over a
hundred years. The file 'northamerica' has a section for the city of Chicago
(which is used to represent US central time), and includes a section that
looks like this:
----------
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/Chicago -5:50:36 - LMT 1883 Nov 18 12:00
-6:00 US C%sT 1920
-6:00 Chicago C%sT 1936 Mar 1 2:00
-5:00 - EST 1936 Nov 15 2:00
-6:00 Chicago C%sT 1942
-6:00 US C%sT 1946
-6:00 Chicago C%sT 1967
-6:00 US C%sT
-----------
The corresponding sections for Eastern (New York), Mountain (Denver) and
Pacific (Los Angeles) are simpler, and don't include anything like the line
Chicago that seems to describe it being in the Eastern zone during 1936.
As a test, to see if mktime() is affected by that weird rule, I changed that
5th line to say:
-8:00 - PST 1936 Nov 15 2:00
Putting Chicago into the Pacific timezone during the summer of 1936, remade
the tzfile with the command
zic -d /tmp/zoneinfo -p America/New_York northamerica
Which created a new file /tmp/zoneinfo/CST6CDT (among others), which I copied
into /usr/share/zoneinfo. I reran my demo scripts from above, and now see:
EST5EDT 1055194982 5
CST6CDT 1055205782 8
MST7MDT 1055202182 7
PST8PDT 1055205782 8
Gotcha! Apparently, the bug is that somehow the rule for what was going on in
Chicago 67 years ago is being misapplied and causing mktime() to give
unexpected results for other years.
Don't know yet if it's the 'zic' program making a mistake creating the
timezone file, or the C library in processing it.
As a workaround, a person could set their machine to Canadian Central time
(Winnipeg), which is similar, but doesn't have the historical baggage and
seems to give the expected results.
Barry
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200307011530.h61FUDAp053481>