Does any one remember the logic behind sp->goback and sp->goahead in localtime.c?

Jonathan Leffler jonathan.leffler at gmail.com
Sun Jan 13 06:48:59 UTC 2008


On Jan 12, 2008 6:52 PM, Kevin Kenny <kkenny2 at nycap.rr.com> wrote:

> Jonathan Leffler wrote:
> > AFAICT, the logic associated with sp->goback and sp->goahead in tzload()
> > and in localsub() in localtime.c could only ever be used if there were
> > at least 800 time change entries, enough for two per year for a 400 year
> > cycle.  And, empirically, there are no time zone definitions in the
> > current (2007k) data set that get anywhere close to this.
> >
> > However, this code can't have been put in there for no reason
> > whatsoever, so I'd like to understand what was the intention - if
> > anybody can remember.
>
> I'm not positive, but I *think* that it was an effort to support solar
> time in the Arab countries; solar time was approximated by making
> several hundred time zone changes *per year*.  The legacy 'solar87,'
> 'solar88' and 'solar89' files in tzdata show what was being tried.
>

Thanks, Kenny.  I'm not sure whether that was it or not.  I think not - but
that was interesting information (I'd not really looked at the solar8x
files).

However, it appears my testing wasn't as thorough as I thought.  Under at
least some circumstances, a zone such as US/Mountain can generate lots of
entries as it goes forward, using the TZ environment variable embedded in
the zone info file.  Life is simpler for places without summer/winter time -
which tend to be close to the equator.

Since I'd got debug code in place that suddenly seemed to start printing, I
was a bit bemused about what I did wrong before - how did I miss it.

[...time passes...]

It was because I switched between a 32-bit and a 64-bit build of the code.
With the 64-bit build and a 64-bit time_t, you can go a lot further forwards
than you can with 32-bit code and a 32-bit time_t, where you're stuck from
early 2038 onwards.

I was right that the extra entries do not appear in the zone info files,
though.

So, I appear to have given a false alarm, for which I apologize.

-- 
Jonathan Leffler <jonathan.leffler at gmail.com>  #include <disclaimer.h>
Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mm.icann.org/pipermail/tz/attachments/20080112/dc5d917a/attachment-0001.html 


More information about the tz mailing list