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.htm>
More information about the tz
mailing list