On Wed, 2 Mar 2016 23:41:22 +0100 Aurelien Jarno 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.
I reproduced this problem on Fedora 23 x86 with glibc 2.22-11.fc23, by building tzcode as follows: $ make clean $ make CFLAGS='-m32' DATEOBJS=date.o date $ TZ=PST+8PDT ./date -r 1152995400 +'%Y-%m-%d %H:%M:%S %z %Z' 2006-07-15 12:30:00 -0800 PST However, if I use GNU glibc built from git (sourceware.org commit 4e940b2f4b577f3a530e0580373f7c2d569f4d63, configured with '../glibc/configure CC=gcc -m32 --build=i486-pc-linux-gnu --prefix=/tmp/prefix') the problem goes away: $ make clean $ make CFLAGS='-m32 -Wl,--rpath=/tmp/prefix/lib -Wl,--dynamic-linker=/tmp/prefix/lib/ld-linux.so.2' DATEOBJS=date.o date $ TZ=PST+8PDT ./date -r 1152995400 +'%Y-%m-%d %H:%M:%S %z %Z' 2006-07-15 13:30:00 -0700 PDT
This is reproducible with GNU libc from git as the date of today.
Which glibc commit were you using? Does it contain any patches compared to upstream glibc? I assume your commit contain the fix for glibc bug 19253. This was fixed in commit c83196b0df4340209f260ffaf90e787c711c268e in November. This issue seems to be on point. See: https://sourceware.org/bugzilla/show_bug.cgi?id=19253 Does the problem go away if you revert commit c83196b0df4340209f260ffaf90e787c711c268e?