From nobody@FreeBSD.org  Tue Feb 27 01:07:33 2007
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id 5CE9316A401
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 27 Feb 2007 01:07:33 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [69.147.83.33])
	by mx1.freebsd.org (Postfix) with ESMTP id 4ED0013C481
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 27 Feb 2007 01:07:33 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.13.1/8.13.1) with ESMTP id l1R17WM2025513
	for <freebsd-gnats-submit@FreeBSD.org>; Tue, 27 Feb 2007 01:07:32 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.13.1/8.13.1/Submit) id l1R17WIj025512;
	Tue, 27 Feb 2007 01:07:32 GMT
	(envelope-from nobody)
Message-Id: <200702270107.l1R17WIj025512@www.freebsd.org>
Date: Tue, 27 Feb 2007 01:07:32 GMT
From: Daniel Crandall<dcrandall@simplestar.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: zdump doesn't work
X-Send-Pr-Version: www-3.0

>Number:         109584
>Category:       amd64
>Synopsis:       [patch] zdump(8) doesn't work
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    edwin
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Tue Feb 27 01:10:02 GMT 2007
>Closed-Date:    Mon Sep 14 11:22:43 UTC 2009
>Last-Modified:  Mon Sep 14 11:22:43 UTC 2009
>Originator:     Daniel Crandall
>Release:        5.4 - 6.2 amd64
>Organization:
Simple Star Inc.
>Environment:
FreeBSD cache001.internal.photoshow.com 6.2-RC2 FreeBSD 6.2-RC2 #0: Sun Dec 24 21:28:09 UTC 2006     root@portnoy.cse.buffalo.edu:/usr/obj/usr/src/sys/SMP  amd64
>Description:
the zdump utility doesn't work on amd64 machines.  I see that this was
reported as a bug a while ago, but for some reason it was categorized as
low priority.  Given the fact that Daylight Saving Time rules have been
changed and this change is to take effect March 12th, it is imperative to
be able to verify whether the installed time zone data is correct.

>How-To-Repeat:
login to a FreeBSD/amd64 machine
`zdump -v /etc/localtime`

What it should do: dump lots of timezone information including DST changes.
What it does: spits out a couple of lines and hangs.
>Fix:

>Release-Note:
>Audit-Trail:

From: Daniel Crandall <dcrandall@simplestar.com>
To: bug-followup@FreeBSD.org, dcrandall@simplestar.com
Cc:  
Subject: Re: amd64/109584: zdump doesn't work
Date: Tue, 27 Feb 2007 10:28:17 -0800

 Additionally, it appears that the time zone files become damaged on the
 amd64 machines.  I copied a good localtime file from a machine on which
 zdump works properly to the amd64 machine.  Tried to zdump it on the
 amd64 box and got the behavior described in this bug.
 
 But then I copied the same file back to a the machine it came from where
 it was known to be good.  Tried to zdump it and it shows the same
 corruption as on the amd64 box.  
 

From: Vasil Dimov <vd@FreeBSD.org>
To: John Baldwin <jhb@freebsd.org>
Cc: freebsd-amd64@freebsd.org, Daniel Crandall <dcrandall@simplestar.com>, wollman@freebsd.org, kensmith@freebsd.org, rwatson@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: amd64/109584: zdump doesn't work
Date: Wed, 28 Feb 2007 08:43:37 +0200

 On Tue, Feb 27, 2007 at 14:54:14 -0500, John Baldwin wrote:
 [...]
 > zdump works by trying to enumerate all the possible 
 > values of time_t.  On a 32-bit machine this means going from -2^31 to
 > 2^31 - 1.  On amd64 which has a 64-bit time_t, this means from from -2^63 to 
 > 2^63 - 1.
 
 Yes, this is true.
 
 > If you understand exponential math you will see that the zone files aren't 
 > corrupted, and zdump isn't hung.  Rather, it's just taking a long time to 
 > run.
 
 I think this is not the case. It is actually hung in infinite loop in
 localtime(3) in libc. Try the following code on amd64 platform:
 
 --- cut ---
 time_t	t;
 t = -9223372036762365600;
 localtime(&t);
 --- cut ---
 
 it hangs in this loop:
 
 src/lib/libc/stdtime/localtime.c:
 1320         y = EPOCH_YEAR;
 1321 #define LEAPS_THRU_END_OF(y)    ((y) / 4 - (y) / 100 + (y) / 400)
 1322         while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) {
 1323                 long    newy;
 1324
 1325                 newy = y + days / DAYSPERNYEAR;
 1326                 if (days < 0)
 1327                         --newy;
 1328                 days -= (newy - y) * DAYSPERNYEAR +
 1329                         LEAPS_THRU_END_OF(newy - 1) -
 1330                         LEAPS_THRU_END_OF(y - 1);
 1331                 y = newy;
 1332         }
 
 where days oscillates between -1 and 365, y and newy between
 -292277022654 and -292277022655. E.g. try so see what happens if you
 enter the loop with days=365 and y=-292277022655.
 
 -- 
 Vasil Dimov
 gro.DSBeerF@dv
 %
 Grelb's Reminder:
         Eighty percent of all people consider themselves to be above
 average drivers.

From: Vasil Dimov <vd@FreeBSD.org>
To: John Baldwin <jhb@freebsd.org>
Cc: freebsd-amd64@freebsd.org, Daniel Crandall <dcrandall@simplestar.com>, wollman@freebsd.org, kensmith@freebsd.org, rwatson@freebsd.org, bug-followup@FreeBSD.org
Subject: Re: amd64/109584: zdump doesn't work
Date: Wed, 28 Feb 2007 09:52:44 +0200

 On Wed, Feb 28, 2007 at 08:43:37 +0200, Vasil Dimov wrote:
 [...]
 > it hangs in this loop:
 > 
 > src/lib/libc/stdtime/localtime.c:
 > 1320         y = EPOCH_YEAR;
 > 1321 #define LEAPS_THRU_END_OF(y)    ((y) / 4 - (y) / 100 + (y) / 400)
 > 1322         while (days < 0 || days >= (long) year_lengths[yleap = isleap(y)]) {
 > 1323                 long    newy;
 > 1324
 > 1325                 newy = y + days / DAYSPERNYEAR;
 > 1326                 if (days < 0)
 > 1327                         --newy;
 > 1328                 days -= (newy - y) * DAYSPERNYEAR +
 > 1329                         LEAPS_THRU_END_OF(newy - 1) -
 > 1330                         LEAPS_THRU_END_OF(y - 1);
 > 1331                 y = newy;
 > 1332         }
 > 
 > where days oscillates between -1 and 365, y and newy between
 > -292277022654 and -292277022655. E.g. try so see what happens if you
 > enter the loop with days=365 and y=-292277022655.
 
 What about this patch:
 
 --- localtime.c_infloop.diff begins here ---
 Index: localtime.c
 ===================================================================
 RCS file: /home/ncvs/src/lib/libc/stdtime/localtime.c,v
 retrieving revision 1.41
 diff -u -r1.41 localtime.c
 --- localtime.c	19 Jan 2007 01:16:35 -0000	1.41
 +++ localtime.c	28 Feb 2007 07:40:24 -0000
 @@ -1326,8 +1326,8 @@
  		if (days < 0)
  			--newy;
  		days -= (newy - y) * DAYSPERNYEAR +
 -			LEAPS_THRU_END_OF(newy - 1) -
 -			LEAPS_THRU_END_OF(y - 1);
 +			LEAPS_THRU_END_OF(newy - (newy > 0 ? 1 : -1)) -
 +			LEAPS_THRU_END_OF(y - (y > 0 ? 1 : -1));
  		y = newy;
  	}
  	tmp->tm_year = y - TM_YEAR_BASE;
 --- localtime.c_infloop.diff ends here ---
 
 -- 
 Vasil Dimov
 gro.DSBeerF@dv
 %
 Everything should be made as simple as possible, but not simpler.
                 -- Albert Einstein

From: "Ken Menzel" <kmenzel@whisolutions.com>
To: <bug-followup@FreeBSD.org>, <dcrandall@simplestar.com>
Cc:  
Subject: Re: amd64/109584: zdump doesn't work
Date: Mon, 5 Mar 2007 15:37:16 -0500

 The patch  did not seem to work for me
 
 This was before the patch:
 cassandra# zdump -v /etc/localtime
 /etc/localtime  Sun Jan 26 08:29:52 -219 UTC = Sun Jan 26 
 03:29:52 -219 EST isdst=0 gmtoff=-18000
 /etc/localtime  Mon Jan 27 08:29:52 -219 UTC = Mon Jan 27 
 03:29:52 -219 EST isdst=0 gmtoff=-18000
 /etc/localtime  Fri Jan  1 04:59:59 -219 UTC = Thu Dec 30 
 23:59:59 -219 EST isdst=0 gmtoff=-18000
 /etc/localtime  Fri Jan  1 05:00:00 -219 UTC = Fri Jan  1 
 00:00:00 -219 EST isdst=0 gmtoff=-18000
 ^C
 
 This was after the patch:
 
  cassandra# zdump -v /etc/localtime
 /etc/localtime  Sun Jan 26 08:29:52 -219 UTC = Sun Jan 26 
 03:29:52 -219 EST isdst=0 gmtoff=-18000
 /etc/localtime  Mon Jan 27 08:29:52 -219 UTC = Mon Jan 27 
 03:29:52 -219 EST isdst=0 gmtoff=-18000
 ^C
 cassandra# uname -a
 FreeBSD cassandra.icarz.com 6.2-RELEASE-p1 FreeBSD 6.2-RELEASE-p1 #2: 
 Wed Feb 28 14:19:29 EST 2007 
 sysadm@cassandra.icarz.com:/usr/obj/usr/src/sys/SMP  amd64
 cassandra#
 
 -----------------------------------------------------
 Ken Menzel
 kmenzel@whisolutions.com
 /earth is 98% full ... please delete anyone you can. 
 

From: Andriy Gapon <avg@icyb.net.ua>
To: bug-followup@FreeBSD.org,  dcrandall@simplestar.com, 
 freebsd-amd64@adam.gs
Cc:  
Subject: Re: amd64/109584: zdump doesn't work
Date: Mon, 26 Mar 2007 14:57:00 +0300

 See thread starting at this messages:
 http://docs.freebsd.org/cgi/getmsg.cgi?fetch=83878+0+archive/2007/freebsd-amd64/20070325.freebsd-amd64
 
 The resolution is to update zdump sources from upstream.
 $ zdump --version
 @(#)zdump.c     8.4
 $ zdump -c 2000,2010 -v EST5EDT
 EST5EDT  Sun Jan 26 08:29:52 -219246529 UTC = Sun Jan 26 03:29:52
 -219246529 EST isdst=0 gmtoff=-18000
 EST5EDT  Mon Jan 27 08:29:52 -219246529 UTC = Mon Jan 27 03:29:52
 -219246529 EST isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  2 06:59:59 2000 UTC = Sun Apr  2 01:59:59 2000 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  2 07:00:00 2000 UTC = Sun Apr  2 03:00:00 2000 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 29 05:59:59 2000 UTC = Sun Oct 29 01:59:59 2000 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 29 06:00:00 2000 UTC = Sun Oct 29 01:00:00 2000 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  1 06:59:59 2001 UTC = Sun Apr  1 01:59:59 2001 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  1 07:00:00 2001 UTC = Sun Apr  1 03:00:00 2001 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 28 05:59:59 2001 UTC = Sun Oct 28 01:59:59 2001 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 28 06:00:00 2001 UTC = Sun Oct 28 01:00:00 2001 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  7 06:59:59 2002 UTC = Sun Apr  7 01:59:59 2002 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  7 07:00:00 2002 UTC = Sun Apr  7 03:00:00 2002 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 27 05:59:59 2002 UTC = Sun Oct 27 01:59:59 2002 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 27 06:00:00 2002 UTC = Sun Oct 27 01:00:00 2002 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  6 06:59:59 2003 UTC = Sun Apr  6 01:59:59 2003 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  6 07:00:00 2003 UTC = Sun Apr  6 03:00:00 2003 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 26 05:59:59 2003 UTC = Sun Oct 26 01:59:59 2003 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 26 06:00:00 2003 UTC = Sun Oct 26 01:00:00 2003 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  4 06:59:59 2004 UTC = Sun Apr  4 01:59:59 2004 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  4 07:00:00 2004 UTC = Sun Apr  4 03:00:00 2004 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 31 05:59:59 2004 UTC = Sun Oct 31 01:59:59 2004 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 31 06:00:00 2004 UTC = Sun Oct 31 01:00:00 2004 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  3 06:59:59 2005 UTC = Sun Apr  3 01:59:59 2005 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  3 07:00:00 2005 UTC = Sun Apr  3 03:00:00 2005 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 30 05:59:59 2005 UTC = Sun Oct 30 01:59:59 2005 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 30 06:00:00 2005 UTC = Sun Oct 30 01:00:00 2005 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  2 06:59:59 2006 UTC = Sun Apr  2 01:59:59 2006 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Apr  2 07:00:00 2006 UTC = Sun Apr  2 03:00:00 2006 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 29 05:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Oct 29 06:00:00 2006 UTC = Sun Oct 29 01:00:00 2006 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Mar 11 06:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Mar 11 07:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Nov  4 05:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Nov  4 06:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Mar  9 06:59:59 2008 UTC = Sun Mar  9 01:59:59 2008 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Mar  9 07:00:00 2008 UTC = Sun Mar  9 03:00:00 2008 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Nov  2 05:59:59 2008 UTC = Sun Nov  2 01:59:59 2008 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Nov  2 06:00:00 2008 UTC = Sun Nov  2 01:00:00 2008 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Mar  8 06:59:59 2009 UTC = Sun Mar  8 01:59:59 2009 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sun Mar  8 07:00:00 2009 UTC = Sun Mar  8 03:00:00 2009 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Nov  1 05:59:59 2009 UTC = Sun Nov  1 01:59:59 2009 EDT
 isdst=1 gmtoff=-14400
 EST5EDT  Sun Nov  1 06:00:00 2009 UTC = Sun Nov  1 01:00:00 2009 EST
 isdst=0 gmtoff=-18000
 EST5EDT  Sat Dec  3 15:30:07 219250468 UTC = Sat Dec  3 10:30:07
 219250468 EST isdst=0 gmtoff=-18000
 EST5EDT  Sun Dec  4 15:30:07 219250468 UTC = Sun Dec  4 10:30:07
 219250468 EST isdst=0 gmtoff=-18000
 
 -- 
 Andriy Gapon
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Sun Apr 22 09:50:25 UTC 2007 
State-Changed-Why:  
To submitter: with the update from upstream, does this problem go away? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109584 

From: Michael Plass <mfp49_freebsd@plass-family.net>
To: bug-followup@FreeBSD.org,
 dcrandall@simplestar.com
Cc:  
Subject: Re: amd64/109584: zdump doesn't work
Date: Wed, 14 Nov 2007 16:54:14 -0800

 Building from upstream sources yields a working zdump with the recipe  
 below.  Note that it uses the upstream localtime.c as well, not the  
 libc version.
 
 $ cd /tmp
 $ mkdir zdumptest
 $ cd zdumptest
 $ fetch ftp://elsie.nci.nih.gov/pub/tzcode2007h.tar.gz
 tzcode2007h.tar.gz                            100% of  185 kB  322 kBps
 $ tar xfz tzcode2007h.tar.gz
 $ make TZDIR=/usr/share/zoneinfo CFLAGS='-D_XOPEN_SOURCE=600' zdump
 cc -DTZDIR=\"/usr/share/zoneinfo\" -D_XOPEN_SOURCE=600 -c zdump.c
 cc -DTZDIR=\"/usr/share/zoneinfo\" -D_XOPEN_SOURCE=600 -c localtime.c
 cc -DTZDIR=\"/usr/share/zoneinfo\" -D_XOPEN_SOURCE=600 -c ialloc.c
 cc -DTZDIR=\"/usr/share/zoneinfo\" -D_XOPEN_SOURCE=600  zdump.o  
 localtime.o ialloc.o  -o zdump
 $ ./zdump -v America/Los_Angeles | grep -w 200.
 America/Los_Angeles  Sun Apr  2 09:59:59 2000 UTC = Sun Apr  2  
 01:59:59 2000 PST isdst=0
 America/Los_Angeles  Sun Apr  2 10:00:00 2000 UTC = Sun Apr  2  
 03:00:00 2000 PDT isdst=1
 America/Los_Angeles  Sun Oct 29 08:59:59 2000 UTC = Sun Oct 29  
 01:59:59 2000 PDT isdst=1
 America/Los_Angeles  Sun Oct 29 09:00:00 2000 UTC = Sun Oct 29  
 01:00:00 2000 PST isdst=0
 America/Los_Angeles  Sun Apr  1 09:59:59 2001 UTC = Sun Apr  1  
 01:59:59 2001 PST isdst=0
 America/Los_Angeles  Sun Apr  1 10:00:00 2001 UTC = Sun Apr  1  
 03:00:00 2001 PDT isdst=1
 America/Los_Angeles  Sun Oct 28 08:59:59 2001 UTC = Sun Oct 28  
 01:59:59 2001 PDT isdst=1
 America/Los_Angeles  Sun Oct 28 09:00:00 2001 UTC = Sun Oct 28  
 01:00:00 2001 PST isdst=0
 America/Los_Angeles  Sun Apr  7 09:59:59 2002 UTC = Sun Apr  7  
 01:59:59 2002 PST isdst=0
 America/Los_Angeles  Sun Apr  7 10:00:00 2002 UTC = Sun Apr  7  
 03:00:00 2002 PDT isdst=1
 America/Los_Angeles  Sun Oct 27 08:59:59 2002 UTC = Sun Oct 27  
 01:59:59 2002 PDT isdst=1
 America/Los_Angeles  Sun Oct 27 09:00:00 2002 UTC = Sun Oct 27  
 01:00:00 2002 PST isdst=0
 America/Los_Angeles  Sun Apr  6 09:59:59 2003 UTC = Sun Apr  6  
 01:59:59 2003 PST isdst=0
 America/Los_Angeles  Sun Apr  6 10:00:00 2003 UTC = Sun Apr  6  
 03:00:00 2003 PDT isdst=1
 America/Los_Angeles  Sun Oct 26 08:59:59 2003 UTC = Sun Oct 26  
 01:59:59 2003 PDT isdst=1
 America/Los_Angeles  Sun Oct 26 09:00:00 2003 UTC = Sun Oct 26  
 01:00:00 2003 PST isdst=0
 America/Los_Angeles  Sun Apr  4 09:59:59 2004 UTC = Sun Apr  4  
 01:59:59 2004 PST isdst=0
 America/Los_Angeles  Sun Apr  4 10:00:00 2004 UTC = Sun Apr  4  
 03:00:00 2004 PDT isdst=1
 America/Los_Angeles  Sun Oct 31 08:59:59 2004 UTC = Sun Oct 31  
 01:59:59 2004 PDT isdst=1
 America/Los_Angeles  Sun Oct 31 09:00:00 2004 UTC = Sun Oct 31  
 01:00:00 2004 PST isdst=0
 America/Los_Angeles  Sun Apr  3 09:59:59 2005 UTC = Sun Apr  3  
 01:59:59 2005 PST isdst=0
 America/Los_Angeles  Sun Apr  3 10:00:00 2005 UTC = Sun Apr  3  
 03:00:00 2005 PDT isdst=1
 America/Los_Angeles  Sun Oct 30 08:59:59 2005 UTC = Sun Oct 30  
 01:59:59 2005 PDT isdst=1
 America/Los_Angeles  Sun Oct 30 09:00:00 2005 UTC = Sun Oct 30  
 01:00:00 2005 PST isdst=0
 America/Los_Angeles  Sun Apr  2 09:59:59 2006 UTC = Sun Apr  2  
 01:59:59 2006 PST isdst=0
 America/Los_Angeles  Sun Apr  2 10:00:00 2006 UTC = Sun Apr  2  
 03:00:00 2006 PDT isdst=1
 America/Los_Angeles  Sun Oct 29 08:59:59 2006 UTC = Sun Oct 29  
 01:59:59 2006 PDT isdst=1
 America/Los_Angeles  Sun Oct 29 09:00:00 2006 UTC = Sun Oct 29  
 01:00:00 2006 PST isdst=0
 America/Los_Angeles  Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11  
 01:59:59 2007 PST isdst=0
 America/Los_Angeles  Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11  
 03:00:00 2007 PDT isdst=1
 America/Los_Angeles  Sun Nov  4 08:59:59 2007 UTC = Sun Nov  4  
 01:59:59 2007 PDT isdst=1
 America/Los_Angeles  Sun Nov  4 09:00:00 2007 UTC = Sun Nov  4  
 01:00:00 2007 PST isdst=0
 America/Los_Angeles  Sun Mar  9 09:59:59 2008 UTC = Sun Mar  9  
 01:59:59 2008 PST isdst=0
 America/Los_Angeles  Sun Mar  9 10:00:00 2008 UTC = Sun Mar  9  
 03:00:00 2008 PDT isdst=1
 America/Los_Angeles  Sun Nov  2 08:59:59 2008 UTC = Sun Nov  2  
 01:59:59 2008 PDT isdst=1
 America/Los_Angeles  Sun Nov  2 09:00:00 2008 UTC = Sun Nov  2  
 01:00:00 2008 PST isdst=0
 America/Los_Angeles  Sun Mar  8 09:59:59 2009 UTC = Sun Mar  8  
 01:59:59 2009 PST isdst=0
 America/Los_Angeles  Sun Mar  8 10:00:00 2009 UTC = Sun Mar  8  
 03:00:00 2009 PDT isdst=1
 America/Los_Angeles  Sun Nov  1 08:59:59 2009 UTC = Sun Nov  1  
 01:59:59 2009 PDT isdst=1
 America/Los_Angeles  Sun Nov  1 09:00:00 2009 UTC = Sun Nov  1  
 01:00:00 2009 PST isdst=0
 $ uname -rsp
 FreeBSD 7.0-BETA2 amd64
 $
 $ exit
 
State-Changed-From-To: feedback->analyzed 
State-Changed-By: linimon 
State-Changed-When: Sun Mar 2 06:39:20 UTC 2008 
State-Changed-Why:  
It sounds like the problem still recurs even with the current version. 
Perhaps another import is needed? 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109584 

Responsible-Changed-From-To: freebsd-amd64->edwin 
Responsible-Changed-By: edwin 
Responsible-Changed-When: Fri Sep 19 01:58:38 UTC 2008 
Responsible-Changed-Why:  
Grab for handling with mentor. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109584 


From: Edwin Groothuis <edwin@mavetju.org>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: amd64/109584: [patch] zdump(8) doesn't work
Date: Fri, 19 Sep 2008 12:00:24 +1000

 Final version
 
 Index: zdump.c
 ===================================================================
 --- zdump.c	(revision 183065)
 +++ zdump.c	(working copy)
 @@ -96,6 +96,15 @@
  #endif /* !defined GNUC_or_lint */
  #endif /* !defined INITIALIZE */
  
 +/* If the size of time_t is bigger than 32 bits, it will take too long to
 + * search from the lowest possible value of a time_t variable to the
 + * highest possible value of a time_t variable.
 + * To overcome this, we put artificial boundaries on this which span two
 + * centuries.
 + */
 +#define	EPOCH1900	-2209024800	/* Mon Jan  1 00:00:00 EST 1900 */
 +#define	EPOCH2100	4102405200	/* Fri Jan  1 00:00:00 EST 2100 */
 +
  /*
  ** For the benefit of GNU folk...
  ** `_(MSGID)' uses the current locale's message library string for MSGID.
 @@ -151,7 +160,10 @@
  	time_t			hibit;
  	struct tm		tm;
  	struct tm		newtm;
 +	int			time_t2;
  
 +	time_t2 = (sizeof(time_t) == 4);
 +
  	INITIALIZE(cuttime);
  #if HAVE_GETTEXT - 0
  	(void) setlocale(LC_MESSAGES, "");
 @@ -222,9 +234,21 @@
  		/*
  		** Get lowest value of t.
  		*/
 -		t = hibit;
 -		if (t > 0)		/* time_t is unsigned */
 -			t = 0;
 +		if (time_t2) {
 +			t = hibit;
 +			if (t > 0)		/* time_t is unsigned */
 +				t = 0;
 +		} else {
 +			/* Set the start time to 1 January 1900 and end time,
 +			 * if no cutoff year specified, to 1 January 2100.
 +			 */
 +			t = EPOCH1900;
 +			if (cutoff == NULL) {
 +				cuttime = EPOCH2100;
 +				cutoff = "2099";
 +			}
 +		}
 +
  		show(argv[i], t, TRUE);
  		t += SECSPERHOUR * HOURSPERDAY;
  		show(argv[i], t, TRUE);
 @@ -253,9 +277,12 @@
  		/*
  		** Get highest value of t.
  		*/
 -		t = ~((time_t) 0);
 -		if (t < 0)		/* time_t is signed */
 -			t &= ~hibit;
 +		if (time_t2) {
 +			t = ~((time_t) 0);
 +			if (t < 0)		/* time_t is signed */
 +				t &= ~hibit;
 +		} else
 +			t = EPOCH2100 - 1;
  		t -= SECSPERHOUR * HOURSPERDAY;
  		show(argv[i], t, TRUE);
  		t += SECSPERHOUR * HOURSPERDAY;
 Index: zdump.8
 ===================================================================
 --- zdump.8	(revision 183065)
 +++ zdump.8	(working copy)
 @@ -43,6 +43,12 @@
  .It Fl c Ar cutoffyear
  Cut off the verbose output near the start of the given year.
  .El
 +.Sh BUGS
 +On systems where
 +.Vt time_t
 +is bigger than 64 bits,
 +the lowest and highest possible time values are artificially limited
 +to 1 January 1900 and 31 December 2099.
  .Sh "SEE ALSO"
  .Xr ctime 3 ,
  .Xr tzfile 5 ,
 
 
 -- 
 Edwin Groothuis      |            Personal website: http://www.mavetju.org
 edwin@mavetju.org    |              Weblog: http://www.mavetju.org/weblog/
State-Changed-From-To: analyzed->patched 
State-Changed-By: edwin 
State-Changed-When: Sat May 23 06:34:59 UTC 2009 
State-Changed-Why:  
Fixed in head in r192625. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=109584 
State-Changed-From-To: patched->closed 
State-Changed-By: edwin 
State-Changed-When: Mon Sep 14 11:22:08 UTC 2009 
State-Changed-Why:  
MFC to stable/7 don. 

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