delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2013/07/27/04:34:12

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 <eliz AT gnu DOT org>
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

> 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 -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019