On 2016-03-02 16:59, Guy Harris wrote:
On Mar 2, 2016, at 2:41 PM, Aurelien Jarno <aurelien@aurel32.net> wrote:
It happens that this patch causes the generated zoneinfo files to not behave correctly wrt daylight saving time on 32-bit machines. On 64-bit machines or before this patch one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 13:30:00 PDT 2006
With this patch on 32-bit machines, one get:
$ TZ=PST+8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
As you can see the daylight saving time is not applied.
What happens with TZ=PST8PDT?
This works as expected.
I don't know if it is a problem in zic or a problem on the GNU libc which doesn't correctly interpret the file. This is reproducible with GNU libc from git as the date of today.
What happens if you remove the PST8PDT link to America/Los_Angeles and use "TZ=PST8PDT"?
It doesn't seems that PST8PDT is a link to America/Los_Angeles, here it is is a different file. That said after removing the file using TZ=PST8PDT starts to show the same issue as with PST+8PDT, that is: $ TZ=PST8PDT date --date=@1152995400 Sat Jul 15 12:30:00 PST 2006
What happens if you remove a link for some zone east of Greenwich and try *that* zone's POSIX specification?
I am not really sure what you mean here. Something like removing the MET file and trying to use for example the MET-1METDST timezone? In that case I get the correct output with and without the file: $ TZ=MET-1METDST date --date=@1152995400 Sat Jul 15 22:30:00 METDST 2006 Thanks, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurelien@aurel32.net http://www.aurel32.net