Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 22 Mar 2007 15:12:47 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        "Olson, Arthur David \(NIH/NCI\) [E]" <olsona@dc37a.nci.nih.gov>
Cc:        wollman@freebsd.org, freebsd-stable@freebsd.org, freebsd-amd64@freebsd.org
Subject:   Re: zdump on amd64
Message-ID:  <460280CF.2090200@icyb.net.ua>
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 22/03/2007 15:06 Olson, Arthur David (NIH/NCI) [E] said the following:
> 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.

Thank you for the pointer!
I guess it is a question of updating FreeBSD sources from upstream now:
$ zdump --version
zdump: @(#)zdump.c      7.31


> -----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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?460280CF.2090200>