Inconsistency with floating's support for 23:59:60

[ikegami]

One would not expect different behaviours from the following snippets:

$ perl -MDateTime -e'
   CORE::say
      DateTime
         ->new(
            year      => 2012,
            month     =>    6,
            day       =>   30,
            hour      =>   23,
            minute    =>   59,
            second    =>   60,
            time_zone => "UTC",
         )
            ->set_time_zone("floating");
'
2012-06-30T23:59:60

$ perl -MDateTime -e'
   CORE::say
      DateTime
         ->new(
            year      => 2012,
            month     =>    6,
            day       =>   30,
            hour      =>   23,
            minute    =>   59,
            second    =>   60,
            time_zone => "floating",
         );
'
Invalid second value (60)
 at -e line 1.

This inconsistency causes DateTime::Format::Strptime to fail.

https://stackoverflow.com/q/60836745/589924

[esabol]

Here's the context:

use DateTime;
use DateTime::TimeZone;
use DateTime::Format::Strptime;

my $utc = DateTime::TimeZone->new(name => 'Etc/UTC');

my $ymdhms_parser = DateTime::Format::Strptime->new(pattern => '%F %T',
                                                    locale => 'en_US',
                                                    time_zone => $utc,
                                                    strict => 1,
                                                    on_error => 'croak');

my $date = '2012-06-30 23:59:60';
print "date: $date\n";
my $dt = $ymdhms_parser->parse_datetime($date);
print "dt: $dt\n";
print "tz: ",$dt->time_zone,"\n";

The output I get is:

date: 2012-06-30 23:59:60
Parsed values did not produce a valid date at /path/to/test.pl line 14.

Versions:

DateTime 1.52
DateTime::LeapSecond 1.52
DateTime::Format::Strptime 1.77

[autarch]

I can't really decide what the right behavior should be. It's possible to argue that the floating TZ should always allow second=60 or to argue it should never allow it.

[esabol]

At a leap second, you can actually get to 60.99999... You don’t actually go to the next day/year until you get to a full 1 second past 23:59:60. (Sorry, that was obvious to you, I’m sure.)

[esabol]

IMO, the problem here is that DateTime::Format::Strptime needs a way to specify the timezone of the date/time being parsed when the string being parsed doesn’t explicitly include the timezone. I assumed that was what the time_zone argument to the constructor was for, but it uses floating instead to instantiate and then converts the DateTime to the specified timezone after instantiation.

[autarch]

@esabol Yeah, that makes sense. I think it'd make more sense to pass the TZ to the constructor. I just wonder if that'd break anyone's code. Damn you, backcompat.

[esabol]

Maybe add another constructor argument to DateTime::Format::Strptime? ‘input_time_zone’ or ‘default_time_zone’ or something like that? And then make it clear in the documentation that ‘time_zone’ is the output timezone.

[autarch]

Yeah, I think an opt in constructor param is the only viable way to do this (or having a DT::Format::Strptime::New class, but that seems uglier to me).