Mail Archives: djgpp-workers/2013/07/26/17:54:48
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 -