Date: Sat, 24 Mar 2007 18:03:33 -0400 From: Adam Jacob Muller <freebsd-amd64@adam.gs> To: "Olson, Arthur David ((NIH/NCI)) [E]" <olsona@dc37a.nci.nih.gov> Cc: freebsd-stable@freebsd.org, Andriy Gapon <avg@icyb.net.ua>, freebsd-amd64@freebsd.org Subject: Re: zdump on amd64 Message-ID: <2DDCB768-6366-4B90-B8A1-0D89F07DCEC0@adam.gs> In-Reply-To: <B410D30A78C6404C9DABEA31B54A2813016CE3E6@nihcesmlbx10.nih.gov> References: <45FE9B11.5030909@icyb.net.ua> <46013D6F.4020704@icyb.net.ua> <B410D30A78C6404C9DABEA31B54A2813016CE3E6@nihcesmlbx10.nih.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mar 22, 2007, at 9:06 AM, Olson, Arthur David ((NIH/NCI)) [E] wrote: > Check the version of zdump in use with a... > zdump --version > ...command; starting with the February 2006 (8.1) version, output > has been limited to run from the year -500 to the year 2500 by > default. The range can be changed using the... > -c [loyear],hiyear > ...option. > > --ado > > -----Original Message----- > From: Andriy Gapon [mailto:avg@icyb.net.ua] > Sent: Wednesday, March 21, 2007 10:13 AM > To: freebsd-amd64@freebsd.org; freebsd-stable@freebsd.org > Cc: wollman@freebsd.org; tz@lecserver.nci.nih.gov > Subject: Re: zdump on amd64 > > on 19/03/2007 16:15 Andriy Gapon said the following: >> Strange problem: >> $ uname -srm >> FreeBSD 6.2-RELEASE-p2 amd64 >> >> $ zdump -v EST >> EST Sun Jan 26 08:29:52 -219 UTC = Sun Jan 26 03:29:52 -219 EST >> isdst=0 >> gmtoff=-18000 >> EST Mon Jan 27 08:29:52 -219 UTC = Mon Jan 27 03:29:52 -219 EST >> isdst=0 >> gmtoff=-18000 >> EST Fri Jan 1 04:59:59 -219 UTC = Thu Dec 30 23:59:59 -219 EST >> isdst=0 >> gmtoff=-18000 >> EST Fri Jan 1 05:00:00 -219 UTC = Fri Jan 1 00:00:00 -219 EST >> isdst=0 >> gmtoff=-18000 >> ^C > ... >> Before each ^C zdump was hanging eating 100% CPU. >> Something about 64-bitness ? > > Hmm. I hurried to assert that it was hanging, it was actually > searching. > It seems that zdump -v algorithm is to start with minimal time_t > possible (large negative number in our case) and to go to maximum > time_t > using 12 hours increments and doing certain checks for DST jumps. > Well, with 64-bit time_t start date is somewhere 200 milliard (10^9) > years ago and end date is the same in the future, so iteration over > those years takes quite a while. And tz db doesn't contain anything > useful for too distant years anyway. > > I think that zdump should be optimized to limit its search range. > At the > very least for the start point - what is current estimate of the > age of > our Universe :-) > > > -- > Andriy Gapon > _______________________________________________ > freebsd-amd64@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-amd64 > To unsubscribe, send any mail to "freebsd-amd64- > unsubscribe@freebsd.org" There is a PR regarding this: http://www.freebsd.org/cgi/query-pr.cgi?pr=109584 Upgrading zdump was not posited as a solution in this PR, if it really does fix the issue the report should be amended ( I will test and do so later if I have time) http://www.freebsd.org/cgi/query-pr.cgi?pr=108841 (dupe closed PR) Irks me a bit that this wasn't considered important enough to deal with before the time zone change here in the US (irks me more that the time zones changed) (DST irks me even more) -Adam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2DDCB768-6366-4B90-B8A1-0D89F07DCEC0>