POSIX::strftime: modified behavior surprises users

[jkeenan]

Our heavy-duty smoke-tester Carlos (@cjg-cguevara) has contacted me about an anomaly on blead perl with the following program:

#!/usr/bin/env perl

use strict;
use warnings;

use POSIX qw(strftime);

print "$^V\n";
print `date '+%s'`;
print strftime('%s', localtime), "\n";

Run it at perl-5.40.0, you get:

$ perl -v | head -2 | tail -1
This is perl 5, version 40, subversion 0 (v5.40.0) built for x86_64-linux

$ perl cjg-foo.pl 
v5.40.0
1719498710
1719498710

Run it at HEAD of blead, you get:

$ bleadperl -v | head -2 | tail -1
This is perl 5, version 41, subversion 1 (v5.41.1 (v5.41.0-106-g99e7291a16)) built for x86_64-linux

$ bleadperl cjg-foo.pl 
v5.41.1
1719498720
1719502320

I adapted his progam to be suitable for bisection:

$ cat strftime-problem.pl 
#!/usr/bin/env perl

use strict;
use warnings;

use POSIX qw(strftime);

my $linux_date = `date '+%s'`;
chomp $linux_date;
my $posix_strftime = strftime('%s', localtime);
my $perl_time = time;

die 'POSIX::strftime anomaly' if (
    ($posix_strftime != $linux_date) 
    ||
    ($posix_strftime != $perl_time) 
);

$ perl strftime-problem.pl 

$ bleadperl strftime-problem.pl 
POSIX::strftime anomaly at strftime-problem.pl line 13.

Bisection pointed to commit 86a9c18b6fab1949a26de790418b8b897a71e4ac:

86a9c18b6fab1949a26de790418b8b897a71e4ac is the first bad commit
commit 86a9c18b6fab1949a26de790418b8b897a71e4ac
Author: Karl Williamson <khw@cpan.org>
Date:   Sun Jun 16 10:17:11 2024 -0600
Commit:     Karl Williamson <khw@cpan.org>
CommitDate: Wed Jun 19 19:50:39 2024 -0600

    Fix up and make sv_strftime_ints() public

    This enhanced function now allows you to specify if you want the system
    to consider the possibility of daylight savings time being in effect.
    Formerly, it was never considered.  As a result, the function is good
    enough to be made public.

If this is a change in the behavior of POSIX::strftime to which we are committed, then (a) we should prepare for a log of complaints starting with the release of perl-5.41.1 (which I hope will be soon); and (b) we will have to figure out how to educate the general perl-using public about that change in behavior.

@khwilliamson and others, please comment. Thanks!

[khwilliamson]

This will be fixed to retain previous behavior Sent from my iPhoneOn Jun 27, 2024, at 9:34 AM, James E Keenan @.> wrote: Our heavy-duty smoke-tester Carlos @.) has contacted me about an anomaly on blead perl with the following program:

!/usr/bin/env perl

use strict; use warnings;

use POSIX qw(strftime);

print "$^V\n"; print date '+%s'; print strftime('%s', localtime), "\n";

Run it at perl-5.40.0, you get: $ perl -v | head -2 | tail -1 This is perl 5, version 40, subversion 0 (v5.40.0) built for x86_64-linux

$ perl cjg-foo.pl v5.40.0 1719498710 1719498710

Run it at HEAD of blead, you get: $ bleadperl -v | head -2 | tail -1 This is perl 5, version 41, subversion 1 (v5.41.1 (v5.41.0-106-g99e7291a16)) built for x86_64-linux

$ bleadperl cjg-foo.pl v5.41.1 1719498720 1719502320

I adapted his progam to be suitable for bisection: $ cat strftime-problem.pl

!/usr/bin/env perl

use strict; use warnings;

use POSIX qw(strftime);

my $linux_date = date '+%s'; chomp $linux_date; my $posix_strftime = strftime('%s', localtime); my $perl_time = time;

die 'POSIX::strftime anomaly' if ( ($posix_strftime != $linux_date) || ($posix_strftime != $perl_time) );

$ perl strftime-problem.pl

$ bleadperl strftime-problem.pl POSIX::strftime anomaly at strftime-problem.pl line 13.

Bisection pointed to commit 86a9c18: 86a9c18b6fab1949a26de790418b8b897a71e4ac is the first bad commit commit 86a9c18b6fab1949a26de790418b8b897a71e4ac Author: Karl Williamson @.> Date: Sun Jun 16 10:17:11 2024 -0600 Commit: Karl Williamson @.> CommitDate: Wed Jun 19 19:50:39 2024 -0600

Fix up and make sv_strftime_ints() public

This enhanced function now allows you to specify if you want the system
to consider the possibility of daylight savings time being in effect.
Formerly, it was never considered.  As a result, the function is good
enough to be made public.

If this is a change in the behavior of POSIX::strftime to which we are committed, then (a) we should prepare for a log of complaints starting with the release of perl-5.41.1 (which I hope will be soon); and (b) we will have to figure out how to educate the general perl-using public about that change in behavior. @khwilliamson and others, please comment. Thanks!

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>