amd64/109584: zdump doesn't work
Daniel Crandall
dcrandall at simplestar.com
Tue Feb 27 22:45:29 UTC 2007
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.
>
More information about the freebsd-amd64
mailing list