[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#665408: marked as done (tzdata: San Luis and Cairo wrongly show UTC)

Your message dated Thu, 17 Dec 2015 19:35:42 +0100
with message-id <20151217183542.GA17446@aurel32.net>
and subject line Re: Bug#665408: tzdata: San Luis and Cairo wrongly show UTC
has caused the Debian Bug report #665408,
regarding tzdata: San Luis and Cairo wrongly show UTC
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
665408: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665408
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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:

--- End Message ---
--- Begin Message --- 
Version: 2.10.1-1

On 2012-10-19 16:59, Aurelien Jarno wrote:
> reassign 665408 libc6
> fixed 665408 2.10.1-1
> thanks
> 
> On Fri, Mar 23, 2012 at 02:40:36PM -0700, Martin Dorey wrote:
> > 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 is indeed the correct patch, hence the problem is in libc6 and not
> in tzdata. I am therefore reassigning the bug and marking it as fixed in
> version 2.10.

This bug was marked as fixed in version 2.10.1-1 but not closed. Doing
that now.

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net

--- End Message ---
Reply to: