Incorrect behaviour with POSIX TZ environment variable

[edglex]

According to ​http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html

"The contents of the environment variable named TZ shall be used by the ctime(), localtime(), strftime(), mktime(), [TSF] ctime_r(), and localtime_r() functions, and by various utilities, to override the default timezone." (on POSIX systems)

This causes a regression test of swi prolog to fail unless the timezone is manually set to CET.

[zooey]

TZ is not being ignored by Haiku, try this:

TZ=EST date

At least for me, this shows the date in EST timezone (which isn't my native one).

I've tried to build swi-prolog, but failed (see bug 626 on haiku-ports for the details).

Can you tell me which of the tests fails?

[edglex]

Replying to zooey:

TZ is not being ignored by Haiku, try this:

TZ=EST date

At least for me, this shows the date in EST timezone (which isn't my native one).

I am now unsure if the bug lies with swi-prolog or haiku, because running "TZ=CEST date" does indeed show me a date in CEST, but "TZ=CET" does not seem to do anything, while "TZ=CET+00:00" causes the swi-prolog tests to pass even though they complain about not getting the expected output. I'm not sure I understand the function of TZ well enough to know what to do about this, but this bug report does indeed seem to be incorrect, or at least about the wrong thing.

I've tried to build swi-prolog, but failed (see bug 626 on haiku-ports for the details).

Can you tell me which of the tests fails?

swi-prolog is building for you now.. so I guess you know the test that is failing - the tests in 'library.pl' which check the output format of various date/time functions. In the main testing script (run by make check) TZ is set to "CET".

[zooey]

Replying to edglex:

Replying to zooey:

TZ is not being ignored by Haiku, try this:

TZ=EST date

At least for me, this shows the date in EST timezone (which isn't my native one).

I am now unsure if the bug lies with swi-prolog or haiku, because running "TZ=CEST date" does indeed show me a date in CEST, but "TZ=CET" does not seem to do anything, while "TZ=CET+00:00" causes the swi-prolog tests to pass even though they complain about not getting the expected output. I'm not sure I understand the function of TZ well enough to know what to do about this, but this bug report does indeed seem to be incorrect, or at least about the wrong thing.

I don't think this bug report is invalid. Maybe there's a problem in both swi-prolog and Haiku. When I played with TZ a bit on Haiku, I noticed that "TZ=EST date" works as intended, but "TZ=CEST date" does not: the latter shows the string "CEST" as timezone, but the printed date actually is the UTC date.

I've tried to build swi-prolog, but failed (see bug 626 on haiku-ports for the details).

Can you tell me which of the tests fails?

swi-prolog is building for you now.. so I guess you know the test that is failing - the tests in 'library.pl' which check the output format of various date/time functions. In the main testing script (run by make check) TZ is set to "CET".

Yes, I've noticed the failing tests, some of which may have wrong expectations, but others seem to indicate a problem with Haiku.

I'll continue to investigate when I find the time.

[edglex]

Replying to zooey:

I'll continue to investigate when I find the time.

Thanks.

For what its worth, running the swi-prolog test with TZ set to CET-02:00 it passes all the format tests except checking the actual time zone. Output is:

'%Z': got 'CET-02:00', expected 'CEST'

[luroh]

Move POSIX compatibility related tickets out of R1 milestone (FutureHaiku/Features).

[jessicah]

I am experiencing similar issues around mktime(), which causes an off-by-one error with the tm.tm_sec field, depending on the configured/specified timezone.

For example, in New Zealand, the test fails; indeed, setting the timezone in the Time preflet to any value of GMT+N:00 will cause the test to fail. Setting the timezone to GMT or GMT-N:00 will pass.

Using the TZ environment variable, TZ=GMT-12:00 ./time-failure fails here, whilst TZ=GMT+12:00 ./time-failure succeeds.

[jessicah]

A quick run of the same on OS X doesn't trigger any assertion failures, fwiw.