From barryp@eden.barryp.org  Sun Jun 29 10:06:04 2003
Return-Path: <barryp@eden.barryp.org>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CB4B237B401
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 29 Jun 2003 10:06:04 -0700 (PDT)
Received: from eden.barryp.org (host-150-32-220-24.midco.net [24.220.32.150])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 189CE4400F
	for <FreeBSD-gnats-submit@freebsd.org>; Sun, 29 Jun 2003 10:06:04 -0700 (PDT)
	(envelope-from barryp@eden.barryp.org)
Received: from barryp by eden.barryp.org with local (Exim 4.20)
	id 19Wfcp-000G0j-3H
	for FreeBSD-gnats-submit@freebsd.org; Sun, 29 Jun 2003 12:06:03 -0500
Message-Id: <E19Wfcp-000G0j-3H@eden.barryp.org>
Date: Sun, 29 Jun 2003 12:06:03 -0500
From: Barry@FreeBSD.ORG, "Pederson <bp"@barryp.org
Sender: Barry Pederson <barryp@eden.barryp.org>
Reply-To: Barry Pederson <bp@barryp.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: mktime gives wrong result in Central timezone
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         53899
>Category:       bin
>Synopsis:       mktime gives wrong result in Central timezone
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jun 29 10:10:08 PDT 2003
>Closed-Date:    Tue Jan 01 08:01:31 UTC 2008
>Last-Modified:  Tue Jan 01 08:01:31 UTC 2008
>Originator:     Barry Pederson
>Release:        FreeBSD 4.8-RELEASE i386
>Organization:
>Environment:
System: FreeBSD eden.barryp.org 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Sat Apr 5 12:35:50 CST 2003 barryp@eden.barryp.org:/usr/obj/usr/src/sys/BARRYP i386


>Description:
	The mktime function seems to give an incorrect result when the timezone
        is set to US Central time.  I first noticed this when running Zope3 (Python)
        unittests, but can also demonstrate the problem using Perl.

>How-To-Repeat:

        Execute mktime() with the same parameters, but vary the TZ enviroment
        variable.  Here is a shell script and a perl script to demonstrate:


------ tzdemo.sh -----------
#!/bin/sh

for tz in 'EST5EDT' 'CST6CDT' 'MST7MDT' 'PST8PDT'
do
    export TZ=$tz;
    /usr/bin/env perl tzdemo.pl $tz
done
----------------------------



------ tzdemo.pl -----------
#!/usr/bin/env perl

use POSIX;

# An arbitrary unix timestamp and its
# gmtime() equivalent.
#

$test_time = 1055176982;
@test_gm = (2, 43, 16, 9, 5, 103, 1, 159, 0);

# You could also say:
#
# @test_gm = gmtime($test_time);

# Convert test time back to a unix timestamp, but since
# mktime() assumes localtime, the result should vary
# according to the current timezone setting
#

$result = mktime(@test_gm);

# Calculate the difference, in hours, between what mktime()
# came up with for a local value  and the initial GMT time
# we started with.
#

$diff = ($result - $test_time) / 3600;

print "$ARGV[0] $result $diff\n";
----------------------------


The expected output is:

  EST5EDT 1055194982 5
  CST6CDT 1055198582 6
  MST7MDT 1055202182 7
  PST8PDT 1055205782 8

The actual output I get is:

  EST5EDT 1055194982 5
  CST6CDT 1055194982 5
  MST7MDT 1055202182 7
  PST8PDT 1055205782 8

The second line (CST6CDT) should not have the same numbers.
>Fix:
>Release-Note:
>Audit-Trail:

From: Barry Pederson <bp@barryp.org>
To: freebsd-gnats-submit@FreeBSD.org
Cc:  
Subject: Re: bin/53899: mktime gives wrong result in Central timezone
Date: Sun, 29 Jun 2003 13:46:49 -0500

 Here's a C equivalent to the Perl script
 that demonstrates the problem.  Compile with:
 
     gcc -o tzdemo tzdemo.c
 
 and alter the tzdemo.sh script to run ./tzdemo
 instead of tzdemo.pl
 
 The output is the same as before, which should
 rule out this being a Perl (or Python) problem.
 
 -------- tzdemo.c ------------
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
 #include <time.h>
 
 int main(int argc, char **argv)
      {
      struct tm test_gm;
      time_t result;
      time_t test_time = 1055176982;
 
      memset(&test_gm, 0, sizeof(test_gm));
      test_gm.tm_sec  = 2;
      test_gm.tm_min  = 43;
      test_gm.tm_hour = 16;
      test_gm.tm_mday = 9;
      test_gm.tm_mon  = 5;
      test_gm.tm_year = 103;
      test_gm.tm_wday = 1;
      test_gm.tm_yday = 159;
      test_gm.tm_isdst = 0;
 
      result = mktime(&test_gm);
 
      printf("%s %d %d\n", getenv("TZ"), (int) result,
           ((int)(result-test_time))/3600);
 
      return 0;
      }
 ---------------------------
 

From: "Nick Triantos" <nick@triantos.com>
To: "'Barry Pederson'" <bp@barryp.org>,
	<FreeBSD-gnats-submit@FreeBSD.org>
Cc:  
Subject: RE: bin/53899: mktime gives wrong result in Central timezone
Date: Sun, 29 Jun 2003 23:47:39 -0700

 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.
 
 -Nick
 
 -----Original Message-----
 From: owner-freebsd-bugs@freebsd.org
 [mailto:owner-freebsd-bugs@freebsd.org] On Behalf Of Barry@FreeBSD.org
 Sent: Sunday, June 29, 2003 10:06 AM
 To: FreeBSD-gnats-submit@FreeBSD.org
 Subject: bin/53899: mktime gives wrong result in Central timezone
 
 
 
 >Number:         53899
 >Category:       bin
 >Synopsis:       mktime gives wrong result in Central timezone
 >Confidential:   no
 >Severity:       non-critical
 >Priority:       medium
 >Responsible:    freebsd-bugs
 >State:          open
 >Quarter:        
 >Keywords:       
 >Date-Required:
 >Class:          sw-bug
 >Submitter-Id:   current-users
 >Arrival-Date:   Sun Jun 29 10:10:08 PDT 2003
 >Closed-Date:
 >Last-Modified:
 >Originator:     Barry Pederson
 >Release:        FreeBSD 4.8-RELEASE i386
 >Organization:
 >Environment:
 System: FreeBSD eden.barryp.org 4.8-RELEASE FreeBSD 4.8-RELEASE #0: Sat
 Apr 5 12:35:50 CST 2003
 barryp@eden.barryp.org:/usr/obj/usr/src/sys/BARRYP i386
 
 
 >Description:
 	The mktime function seems to give an incorrect result when the
 timezone
         is set to US Central time.  I first noticed this when running
 Zope3 (Python)
         unittests, but can also demonstrate the problem using Perl.
 
 >How-To-Repeat:
 
         Execute mktime() with the same parameters, but vary the TZ
 enviroment
         variable.  Here is a shell script and a perl script to
 demonstrate:
 
 
 ------ tzdemo.sh -----------
 #!/bin/sh
 
 for tz in 'EST5EDT' 'CST6CDT' 'MST7MDT' 'PST8PDT'
 do
     export TZ=$tz;
     /usr/bin/env perl tzdemo.pl $tz
 done
 ----------------------------
 
 
 
 ------ tzdemo.pl -----------
 #!/usr/bin/env perl
 
 use POSIX;
 
 # An arbitrary unix timestamp and its
 # gmtime() equivalent.
 #
 
 $test_time = 1055176982;
 @test_gm = (2, 43, 16, 9, 5, 103, 1, 159, 0);
 
 # You could also say:
 #
 # @test_gm = gmtime($test_time);
 
 # Convert test time back to a unix timestamp, but since
 # mktime() assumes localtime, the result should vary
 # according to the current timezone setting
 #
 
 $result = mktime(@test_gm);
 
 # Calculate the difference, in hours, between what mktime()
 # came up with for a local value  and the initial GMT time
 # we started with.
 #
 
 $diff = ($result - $test_time) / 3600;
 
 print "$ARGV[0] $result $diff\n";
 ----------------------------
 
 
 The expected output is:
 
   EST5EDT 1055194982 5
   CST6CDT 1055198582 6
   MST7MDT 1055202182 7
   PST8PDT 1055205782 8
 
 The actual output I get is:
 
   EST5EDT 1055194982 5
   CST6CDT 1055194982 5
   MST7MDT 1055202182 7
   PST8PDT 1055205782 8
 
 The second line (CST6CDT) should not have the same numbers.
 >Fix:
 >Release-Note:
 >Audit-Trail:
 >Unformatted:
 _______________________________________________
 freebsd-bugs@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
 To unsubscribe, send any mail to "freebsd-bugs-unsubscribe@freebsd.org"
 

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
 

From: David MCNETT <nugget@slacker.com>
To: freebsd-gnats-submit@FreeBSD.org, bp@barryp.org
Cc: stefanf@freebsd.org
Subject: Re: bin/53899: mktime gives wrong result in Central timezone
Date: Wed, 1 Dec 2004 12:34:05 -0600

 Barry did all the heavy lifting with this issue, I just wanted to clear 
 up any remaining confusion.
 
 In researching this issue further I learned that the bug cannot be 
 reproduced on a 6.0-CURRENT or RELENG_5 machine.  The behavior still 
 exists on any 4.x machine and on older 5.x machines leading me to 
 speculate that this problem may have been resolved as a byproduct of 
 the tzcode2004a import performed by stefanf in June 2004.
 
 4.10-STABLE, 21-Oct-2004 exhibits the bug
 5.2.1-RELEASE-p5, 20-Apr-2004 exhibits the bug
 5.3-STABLE, 7-Nov-2004 is correct
 6.0-RELEASE, 1-Dec-2004 is correct.
 
 I also determined that the problem is not within the zic code.  MD5 
 sums match on the generated /usr/share/zoneinfo/America/Chicago files 
 when comparing an affected 4.x machine to a 6-CURRENT machine which 
 does not exhibit the behavior.  If zic on both systems is producing the 
 same compiled zone files then it would appear that the problem is in 
 libc when parsing the data.
 
 It would be nice if the tzcode2004a import, specifically the libc bits, 
 could be MFC'd into RELENG_4 prior to 4.11-RELEASE, especially since 
 4.11 is expected to be the final 4.x release.
 
 I was never able to determine what the deal was in Chicago on 
 1-Mar-1936.
 
State-Changed-From-To: open->closed 
State-Changed-By: edwin 
State-Changed-When: Tue Jan 1 07:58:45 UTC 2008 
State-Changed-Why:  
It is believed that this issue is resolved in the current FreeBSD 
versions. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=53899 
>Unformatted:
