Date: Tue, 27 Feb 2007 14:25:32 -0800 From: Daniel Crandall <dcrandall@simplestar.com> To: John Baldwin <jhb@freebsd.org> Cc: wollman@freebsd.org, kensmith@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: amd64/109584: zdump doesn't work Message-ID: <1172615132.5198.34.camel@localhost.localdomain> In-Reply-To: <200702271454.14774.jhb@freebsd.org> References: <200702271920.l1RJK8fo042824@freefall.freebsd.org> <200702271454.14774.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. > > 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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1172615132.5198.34.camel>