X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f X-Recipient: djgpp-workers AT delorie DOT com Date: Sat, 27 Jul 2013 11:33:56 +0300 From: Eli Zaretskii Subject: Re: zoneinfo not able to recognize if daylight saving time is in effect. In-reply-to: <51F2F068.2040504@gmx.de> X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp-workers AT delorie DOT com Message-id: <83fvv0z9jf.fsf@gnu.org> References: <51F2C9B5 DOT 3090202 AT gmx DOT de> <83li4tyvcx DOT fsf AT gnu DOT org> <83iozxyuzm DOT fsf AT gnu DOT org> <51F2F068 DOT 2040504 AT gmx DOT de> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Fri, 26 Jul 2013 23:55:52 +0200 > From: Juan Manuel Guerrero > > > 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.