amd64/109584: zdump doesn't work

[Daniel Crandall]

Thanks!  I appreciate the detail and provided work around.

dc

On Tue, 2007-02-27 at 14:54 -0500, John Baldwin wrote:
> On Tuesday 27 February 2007 14:20, Daniel Crandall wrote:
> > The following reply was made to PR amd64/109584; it has been noted by GNATS.
> > 
> > From: Daniel Crandall <dcrandall at simplestar.com>
> > To: bug-followup at FreeBSD.org, dcrandall at 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.  
> 
> It's not corruption.  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.
> 
> 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.  Specifically, at work I timed the 32-bit zdump -v as taking about 0.05 
> seconds of wall time.  If the same box did a full 64-bit zdump -v run it 
> would take about 4294967296 * 0.05 = 214748364.80 seconds to run.  Well,
> some simple math shows:
> 
> 214748364.80
> last / 60
> 3579139.4133
> last / 60
> 59652.3235
> last / 24
> 2485.5134
> last / 365.25
> 6.8049
> 
> Yes, 6.8 _years_ for zdump -v to finish. :)  Apparently the tzcode code that 
> zdump comes from has been updated by the vendor to add some limits on the 
> time_t values searched (-500 years to +2500 years IIRC).  Hopefully we can 
> get the newer zdump imported into the base system to resolve this issue on 
> 64-bit platforms.  For now you can simply make use of date -r with a known 
> time_t to see if your system is up to date.  For example, on EST5EDT (Eastern 
> time) this should show up:
> 
> % date -r 1173596400
> Sun Mar 11 03:00:00 EDT 2007
> 
> If you don't have the updated file, then you would see 2am EST instead.  For 
> PST8PDT (Pacific time) use 1173607200.
>