delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2013/07/26/17:54:48

X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f
X-Recipient: djgpp-workers AT delorie DOT com
Message-ID: <51F2F068.2040504@gmx.de>
Date: Fri, 26 Jul 2013 23:55:52 +0200
From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121025 Thunderbird/16.0.2
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: zoneinfo not able to recognize if daylight saving time is in
effect.
References: <51F2C9B5 DOT 3090202 AT gmx DOT de> <83li4tyvcx DOT fsf AT gnu DOT org> <83iozxyuzm DOT fsf AT gnu DOT org>
In-Reply-To: <83iozxyuzm.fsf@gnu.org>
X-Provags-ID: V03:K0:WLtflMBMyYQ05HlyZOyJ+pPti8sfyX0qJysf/zuJYjT3Rm0uh+G
xotdpCeF8fU+7/UgiVF7Nd6xWFukG+RFT80AdUbh2fXMs3WUr+qef8m46cYdGBKCr97HcRe
tNRoZ8ZeBQGn2q4iK5UsbBvxrR/SvoX3nPMEFrBFycYqBNBF4n8+y01m7vt5AjXlXyLndlt
b4uFVfXBnmOZxAd6OY6dw==
Reply-To: djgpp-workers AT delorie DOT com

Am 26.07.2013 21:35, schrieb Eli Zaretskii:

 > > Date: Fri, 26 Jul 2013 21:10:45 +0200
 > > From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
 > >
 > > int main (int argc, char **argv) {
 > >    int fail = 0;
 > >    static char env_string[] = "TZ=:America/New_York";
 >                                     ^
 > What is that colon doing there?  AFAIR, the value of TZ should point
 > to the file name with the timezone information, and that's it. No
 > colons, no nothing.
 >
 > Anyway, the test program works for me, with the original djdev203
 > timezone files.

That is unix syntax for the TZ environment variable and djgpp was able to
deal with this since v2_00 tag of ctime.c.  See ctime.c:tzload. Here an
existing colon at the beginning of the environment string is skipped before
the string is concatenated with "/dev/env/DJDIR/zoneinfo".  There is no
difficulty in locating and loading the file.

[snip]
 > 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.


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


 > > Date: Fri, 26 Jul 2013 22:27:58 +0300
 > > From: Eli Zaretskii <eliz AT gnu DOT org>
 > >
 > > 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?


2) If I run the test code using my stock 2.04 installation that uses
djtzn204.zip (time stamp of the dsm file is 2003-11-30) I get:

time_t 1372780800  expected 2013-07-02 12:00:00 EDT
                         got 2013-07-02 12:00:00 EDT
Test passed

This is no surprise.  An inspection of the repository shows that the
timezone database has not been updated until end of 2012.
2.04 uses the same outdated database and produces the same
"correct" result like 2.03 does.


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.


- Raw text -


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