Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Mar 2007 16:13:03 +0200
From:      Andriy Gapon <avg@icyb.net.ua>
To:        freebsd-amd64@freebsd.org,  freebsd-stable@freebsd.org
Cc:        wollman@FreeBSD.org, tz@elsie.nci.nih.gov
Subject:   Re: zdump on amd64
Message-ID:  <46013D6F.4020704@icyb.net.ua>
In-Reply-To: <45FE9B11.5030909@icyb.net.ua>
References:  <45FE9B11.5030909@icyb.net.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
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?46013D6F.4020704>