Mail Archives: djgpp-workers/2013/07/27/04:34:12
> Date: Fri, 26 Jul 2013 23:55:52 +0200
> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
>
> > The 2 failures in 2.03 are because US timezone rules were changed in
> > 2007, and 2.03 doesn't have those new rules in its timezone database.
> > The failures are precisely in March and November, which were affected
> > by the change. Import the latest timezone database, and the problem
> >should go away.
>
> I am aware of this. The user told me about this.
Then what exactly is the issue we are discussing? If the zoneinfo
database is outdated, one should expect failures here and there.
I mean, it would be nice to have all the information that you have,
including what you know and don't know, and what are the issues where
you are seeking help, be spelled out, so that we could concentrate on
them, instead of exploring things you already did and understood.
> > As for 2.04, I don't know which timezone database it uses. Did
> > someone bother to update from upstream?
>
> I do not know what timezone database is used by 2.04, but I have updated
> the repository code with tzcode2012j.tar.gz and tzdata2012j.tar.gz.
> See http://www.delorie.com/archives/browse.cgi?p=djgpp-workers/2012/12/04/13:10:10
> and later. I downloaded the archives from ftp://ftp.iana.org/tz/. Have I
> missed to download something more? According to what I have read there
> everything what is required are the matching code and data archives and
> nothing more. Or am I missing something?
I don't think you miss something, assuming that, after downloading the
tz files, you re-generated to zoneinfo files DJGPP uses, in the
zoneinfo/ directory, and that nothing went wrong during that
generation.
> > > Anyway, the test program works for me, with the original djdev203
> > > timezone files.
> >
> > I meant the only un-ifdef'ed away test works. Of the others, 2 fail.
>
> I have intentionally focused on this single line. I will base all analysis only
> on this particular code line (time value).
>
> 1) If I run the test code using my stock 2.03 installation that uses
> djtzn203.zip (time stamp of the dsm file is 2000-04-13) I get:
>
> time_t 1372780800 expected 2013-07-02 12:00:00 EDT
> got 2013-07-02 12:00:00 EDT
> Test passed
>
> It is well known that the timezone database is outdated.
> Why is the "correct" result produced?
> Fortunate coincidence?
It passes because July was in EDT back when we updated the zoneinfo
files, and still is today.
All that the zoneinfo files tell is what is the offset from UTC during
standard time, what is the offset during the daylight savings time,
and what are the rules to decide when to switch between the standard
and daylight savings time. The offsets didn't change for New York
since 2.03 was released (and probably never will, not in our
lifetime), but the switch rules did change in 2007. However, these
rules only affect the dates around March-April and October-November,
which is when the switch happens. Before 2007, the switch happened on
a fixed date, after 2007 there are more complex rules like "2nd Sunday
of March".
That is why you get failures around March and November, but not in
July.
> 3) If I run the test code using my repository installation that uses
> the database from tzdata2012j.tar.gz I get:
>
> time_t 1372780800 expected 2013-07-02 12:00:00 EDT
> got 2013-07-02 11:00:00 EST FAIL
> Test FAILED
>
> Although the database has been updated, now the result is certainly wrong.
The obvious conclusion is that the new database is somehow wrong.
tzdata2012j.tar.gz has these rules in 'northamerica' file:
Rule US 2007 max - Mar Sun>=8 2:00 1:00 D
Rule US 2007 max - Nov Sun>=1 2:00 0 S
# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone America/New_York -4:56:02 - LMT 1883 Nov 18 12:03:58
-5:00 US E%sT 1920
-5:00 NYC E%sT 1942
-5:00 US E%sT 1946
-5:00 NYC E%sT 1967
-5:00 US E%sT
This should cause America/New_York use the "US" rules from 1967 on,
and in particular, the above two "US" rules since 2007. If that
doesn't happen, maybe something went wrong when this was translated to
the zoneinfo files?
I vaguely remember that the tzcode sources needed changes to produce
correct results, something with byte reversal, perhaps? I suggest to
make sure those changes are propagated to v2.04 and to the programs
you used to generate the zoneinfo DB. Here are the mails that probably
was the origin of my vague memory:
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2000/04/20/13:29:28
http://www.delorie.com/djgpp/mail-archives/browse.cgi?p=djgpp/2000/04/11/16:50:20
Since those mail threads are related to cross-compiled DJGPP, those
problems are probably not relevant to this one, as long as we are
talking about zoneinfo files produced natively on DOS/Windows using
DJGPP.
If worse comes to worst, yes, you will have to step through the code
that reads the DST rules and see what's wrong there.
- Raw text -