bin/53899: mktime gives wrong result in Central timezone

[Barry Pederson]

The following reply was made to PR bin/53899; it has been noted by GNATS.

From: Barry Pederson <bp at barryp.org>
To: Nick Triantos <nick at triantos.com>
Cc: FreeBSD-gnats-submit at 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