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