Bug#107320: POSIX::strftime doesn't handle daylight switch correctly

[Niko Tyni]

tag 107320 - wontfix
forwarded 107320 http://rt.perl.org/rt3/Public/Bug/Display.html?id=18238
close 107320 5.8.1-1
thanks

On Thu, Aug 02, 2001 at 03:38:04PM +1000, Brendan O'Dea wrote:
> On Wed, Aug 01, 2001 at 12:32:22AM -0400, Francis J. Lacoste wrote:
> >Package: perl
> >Version: 5.6.1-5
> >Severity: normal
> >
> >In the Canada/Eastern timezone, January 1st is in standard time (EST)
> >and July 1st is in EDT.
> >
> >date "+%s %z" --date 2001-01-01 
> >978325200 -0500
> >
> >date "+%s %z" --date 2001-07-01 
> >993960000 -0400
> >
> >But perl gives :
> >
> >perl -MPOSIX=strftime -e 'print strftime("%s %z", localtime 978325200 ), "\n"'
> >978325200 -0400
> >perl -MPOSIX=strftime -e 'print strftime("%s %z", localtime 993960000 ), "\n"'
> >993960000 -0400
> >
> >As you see, it thinks that both are in EDT and it doesn't look like with
> >a problem in the C library or the locale data because date is giving
> >the correct result.
> 
> Unfortunately this is a limitation of the way strftime is implemented in
> the POSIX module.  See http://bugs.debian.org/48277 for a related
> problem.
> 
> The issue is basically that the timezone name and time offset in the tm
> struct are not portable, hence not produced by the output of localtime
> or taken as arguments to strftime.

If I understand this correctly, upstream change 18267 (first included in
Debian with 5.8.1) solved this by making strftime do an an extra mktime(3)
call to get the tm_gmtoff and tm_zone fields from libc where possible.

 http://perl5.git.perl.org/perl.git/commitdiff/c473feecc2

The original testcase certainly works better now with both 5.8.8 and
5.10.0, so closing the bug.
-- 
Niko Tyni   ntyni at debian.org