Package: tzdata Version: 2011n-0lenny1 Severity: normal On a server with tzdata 2009l-0lenny1:
dsatow@mercury11:~$ LANG= TZ=America/Argentina/San_Luis date Thu Mar 22 21:41:43 WART 2012 dsatow@mercury11:~$ LANG= TZ=Africa/Cairo date Fri Mar 23 03:41:55 EET 2012 dsatow@mercury11:~$ On a server with 2011n-0llenny1: martind@whitewater:~$ LANG= TZ=America/Argentina/San_Luis date Fri Mar 23 18:30:10 UTC 2012 martind@whitewater:~$ LANG= TZ=Africa/Cairo date Fri Mar 23 18:30:11 UTC 2012 martind@whitewater:~$ "WART" and "EET" change to "UTC". I believe this to be incorrect. This does not happen with the Squeeze libc and the same Lenny tzdata. I suspect that this was the fix: http://cygwin.com/ml/libc-alpha/2009-06/msg00102.html This demonstrates that the problem applies to many zones: for zone in `find /usr/share/zoneinfo/ -type f` do echo $zone; zdump -v $zone | tail -3 | head -1 done | grep UTC' isdst' Most such zones will only be affected tens of years in the future. The only zones, as of tzdata 2011k-0lenny1, that are currently affected are San Luis, Cairo and Egypt. All the affected zonefiles end with \x0A\x0A. But not all the zonefiles ending in such a way are affected. This casts doubt on my suspected fix. All such exceptions are under the right/ tree: martind@whitewater:~$ TZ=/usr/share/zoneinfo/right/America/Argentina/San_Luis date Fri Mar 23 17:30:06 WARST 2012 martind@whitewater:~$ hexdump -C /usr/share/zoneinfo/right/America/Argentina/San_Luis | tail -2 00000640 00 00 00 0a 0a |.....| 00000645 martind@whitewater:~$ I suspect, though, that the reason that appears to work is another bug, fixed here: http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=6355c99740c91ed5a7fa14e378f74950e09f5f48 I think that would prevent the empty tzspec from being read, except in the case where num_leaps is zero, explaining why that only afflicts the right/ tree. Returning to the original bug, this came to afflict San Luis in 2010j-0lenny1. 2010f-0lenny1 didn't exhibit the problem. It was a tzdata update, then, that led me to trip over the problem, which is part of the reason for my reporting a libc6 bug against tzdata. I don't expect, or even hope, for this to be fixed in Lenny. I would just like the report available to search engines so that the next person doesn't spend so long on it. I'd also like to raise awareness of the (small) risk of updating tzdata without updating libc6's tzfile code. -- System Information: Debian Release: 5.0.10 APT prefers oldstable APT policy: (500, 'oldstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.24 Debian configuration management sy tzdata recommends no packages. tzdata suggests no packages. -- debconf information: tzdata/Zones/Australia: tzdata/Zones/Asia: tzdata/Zones/SystemV: tzdata/Zones/Pacific: tzdata/Zones/Atlantic: tzdata/Zones/US: tzdata/Zones/Etc: tzdata/Zones/Arctic: tzdata/Zones/Antarctica: * tzdata/Zones/Europe: Paris tzdata/Zones/Africa: * tzdata/Zones/America: Los_Angeles * tzdata/Areas: America tzdata/Zones/Indian: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
