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 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> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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 > > > > 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 > > > > 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.