amd64/109584: zdump doesn't work

[John Baldwin]

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.

-- 
John Baldwin