Bug#665408: tzdata: San Luis and Cairo wrongly show UTC

[Martin Dorey <mdorey@bluearc.com>]

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: