# FW: time zone library

Olson, Arthur David (NIH/NCI) [E] olsona at dc37a.nci.nih.gov
Mon Jan 12 18:09:02 UTC 2009

I'm forwarding this message from John Dlugosz, who is not on the time
zone mailing list. Those of you who are on the list, please direct
replies appropriately.

-----Original Message-----
From: John Dlugosz [mailto:JDlugosz at TradeStation.com]
Sent: Tuesday, January 06, 2009 7:10
To: tz at lecserver.nci.nih.gov
Subject: time zone library

been figuring out how it works.  I have a few questions, and also
(hopefully) a contribution.

First, my contribution.
Regarding
/*
** Adapted from code provided by Robert Elz, who writes:
**	The "best" way to do mktime I think is based on an idea
of Bob
**	Kridle's (so its said...) from a long time ago.
**	It does a binary search of the time_t space. Since
time_t's are
**	just 32 bits, its a max of 32 iterations (even at 64
bits it
**	would still be very reasonable).
*/

I'm using 64-bit time_t values, and find that it usually takes 62 to 64
iterations.  Basically, it is always worst case.

I tried using a rough guess for the initial hi and low:

lo =  ((yourtm.tm_year-70) * 365i64 + yourtm.tm_mon * 28) *
SecondsPerDay;
hi =  ((yourtm.tm_year-70) * 366i64 + (yourtm.tm_mon+1)*31) *
SecondsPerDay;

when the resulting time_t would be positive, and it completes in 20 to
23 iterations.  I punted on the negative case, but a very similar
calculation would work.

When tm_year < 70, I just used the smallest value I care about for lo,
and 0 for hi.  That gives me worst case 35 iterations, because I'm only
supporting values back to 1752 CE, not the full range of a 64-bit
number, which would be 21 times longer than the age of the universe.

Now for my first question.  TZ_MAX_TIMES is 1200, and that is exactly
the length of the arrays for state::ats and state::types.  I suppose it
is noting every time change, e.g. DST adjustments twice a year for 600
years?  There is no need to store anything before the first reported
time in the configuration files, as it simply uses the first entry for
anything older (no DST in pre-history); it seems to have code for
dealing with dates beyond the end of the table.  Does it extrapolate the
current DST rule in the future?

I'd like to cut off the table at a more reasonable date for my
application.  Where is that table populated?  Is it when the data file
is loaded, or in zic when it is created?

My second question concerns leap seconds.  It appears that the leap
second data is associated with every zone file.  Why isn't it simply the
same for everything, and global?

--John