FAQ

[DateTime] Serious Problem - DateTime::Timezone 0.89 when set to Africa / Cairo throws exception right now

Shane McCarron
Apr 24, 2009 at 2:20 pm
Right now (seconds since the epoch 1240582619 more or less) if I attempt
to create a datetime object using that value in the Afirca / Caori
timezone, I am getting an exception:

//Invalid local time for date in time zone: Africa/Cairo

Stack:
[C:\Perl\site\lib\DateTime\TimeZone.pm:209]
[C:\Perl\site\lib\DateTime\TimeZone.pm:164]
[C:\Perl\site\lib\DateTime.pm:870]
[C:\Perl\site\lib\DateTime.pm:335]
[C:\Perl\site\lib\DateTime.pm:215]
[C:\Perl\site\lib\DateTime.pm:250]
[C:\Perl\site\lib\DateTime.pm:1824]
[C:\Perl\site\lib\DateTime.pm:477]
//


I have a customer who is down because of this. Any suggestions?

--
Shane P. McCarron Phone: +1 763 786-8160 x120
Managing Director Fax: +1 763 786-8180
ApTest Minnesota Inet: shane@aptest.com
reply

Search Discussions

10 responses

  • Shane McCarron at Apr 24, 2009 at 2:32 pm
    Actually, I was wrong - this is a call to DateTime->today. As in:

    my $d = DateTime->today(time_zone => "Africa/Cairo") ;

    This is failing with the exception below. Help?

    Shane McCarron wrote:
    Right now (seconds since the epoch 1240582619 more or less) if I
    attempt to create a datetime object using that value in the Afirca /
    Caori timezone, I am getting an exception:

    //Invalid local time for date in time zone: Africa/Cairo

    Stack:
    [C:\Perl\site\lib\DateTime\TimeZone.pm:209]
    [C:\Perl\site\lib\DateTime\TimeZone.pm:164]
    [C:\Perl\site\lib\DateTime.pm:870]
    [C:\Perl\site\lib\DateTime.pm:335]
    [C:\Perl\site\lib\DateTime.pm:215]
    [C:\Perl\site\lib\DateTime.pm:250]
    [C:\Perl\site\lib\DateTime.pm:1824]
    [C:\Perl\site\lib\DateTime.pm:477]
    //


    I have a customer who is down because of this. Any suggestions?
    --
    Shane P. McCarron Phone: +1 763 786-8160 x120
    Managing Director Fax: +1 763 786-8180
    ApTest Minnesota Inet: shane@aptest.com
  • Evan Carroll at Apr 24, 2009 at 2:39 pm
    I can confirm,

    ecarroll@rda:~$ perl -MDevel::SimpleTrace -MDateTime -e'my $d =
    DateTime->today(time_zone => "Africa/Cairo") ;'
    Invalid local time for date in time zone: Africa/Cairo
    at DateTime::TimeZone::_span_for_datetime(unknown source)
    at DateTime::TimeZone::offset_for_local_datetime(/usr/local/share/perl/5.10.0/DateTime/TimeZone.pm:164)
    at DateTime::_offset_for_local_datetime(/usr/local/lib/perl/5.10.0/DateTime.pm:870)
    at DateTime::_calc_utc_rd(/usr/local/lib/perl/5.10.0/DateTime.pm:335)
    at DateTime::new(/usr/local/lib/perl/5.10.0/DateTime.pm:215)
    at DateTime::_new_from_self(/usr/local/lib/perl/5.10.0/DateTime.pm:250)
    at DateTime::truncate(/usr/local/lib/perl/5.10.0/DateTime.pm:1824)
    at DateTime::today(/usr/local/lib/perl/5.10.0/DateTime.pm:477)
    at main::(-e:1)

    # This means someone gave a local time that doesn't exist
    # (like during a transition into savings time)
    unless ( defined $span )
    {
    my $err = 'Invalid local time for date';
    $err .= ' ' . $dt->iso8601 if $type eq 'utc';
    $err .= " in time zone: " . $self->name;
    $err .= "\n";

    die $err;
    }


    I'm afraid I'm left to conclude Cario is dead. I'll check it out later
    today, interesting find.
    --
    Evan Carroll
    System Lord of the Internets
  • Zefram at Apr 24, 2009 at 2:52 pm
    perl -MDevel::SimpleTrace -MDateTime -e'my $d = DateTime->today(time_zone => "Africa/Cairo") ;'
    This is failing because it attempts to construct 00:00 local time in the
    specified timezone, but today there was no 00:00 in Cairo. DST took
    effect at what would have been that instant, so the local time jumped
    from 2009-04-23T23:59:59+02 to 2009-04-24T01:00:00+03.

    -zefram
  • Evan Carroll at Apr 24, 2009 at 3:25 pm
    Shouldn't it be in the docs if ->today() isn't a safe call, or should
    ->today, start at times other than 00:00 during dst.

    --
    Evan Carroll
    System Lord of the Internets
  • Shane McCarron at Apr 24, 2009 at 4:40 pm
    Wow - sounds like a bug to me. Ick.

    Zefram wrote:
    perl -MDevel::SimpleTrace -MDateTime -e'my $d = DateTime->today(time_zone => "Africa/Cairo") ;'
    This is failing because it attempts to construct 00:00 local time in the
    specified timezone, but today there was no 00:00 in Cairo. DST took
    effect at what would have been that instant, so the local time jumped
    from 2009-04-23T23:59:59+02 to 2009-04-24T01:00:00+03.

    -zefram
    --
    Shane P. McCarron Phone: +1 763 786-8160 x120
    Managing Director Fax: +1 763 786-8180
    ApTest Minnesota Inet: shane@aptest.com
  • Zefram at Apr 24, 2009 at 4:53 pm

    Shane McCarron wrote:
    Wow - sounds like a bug to me. Ick.
    A bug in what, though? DateTime->today is documented to behave like a
    truncate-to-day operation, which implies setting to 00:00 local time.
    Do you want to change the semantics of truncate? Or make ->today
    cleverer? Or is ->today the wrong approach for this application?

    Most timezones avoid changing offset at midnight, in order to avoid
    this kind of issue. It's handy for midnight to always be well defined.
    So is this a bug in Egyptian DST rules?

    -zefram
  • Shane McCarron at Apr 24, 2009 at 5:18 pm
    You could argue it is a bug in the definition of the timezone, but we
    don't really have any control over that, do we? It was pretty
    unexpected to get an exception from this method - I certainly don't want
    to have to wrap all my DateTime calls in a eval just because the
    underlying framework is that unreliable. There has to be a way that the
    today method can ensure it isn't doing anything insane... doesn't there?

    Zefram wrote:
    Shane McCarron wrote:
    Wow - sounds like a bug to me. Ick.
    A bug in what, though? DateTime->today is documented to behave like a
    truncate-to-day operation, which implies setting to 00:00 local time.
    Do you want to change the semantics of truncate? Or make ->today
    cleverer? Or is ->today the wrong approach for this application?

    Most timezones avoid changing offset at midnight, in order to avoid
    this kind of issue. It's handy for midnight to always be well defined.
    So is this a bug in Egyptian DST rules?

    -zefram
    --
    Shane P. McCarron Phone: +1 763 786-8160 x120
    Managing Director Fax: +1 763 786-8180
    ApTest Minnesota Inet: shane@aptest.com
  • Metz, Bobby at Apr 24, 2009 at 6:48 pm

    Zefram wrote:
    Shane McCarron wrote:
    Wow - sounds like a bug to me. Ick.
    A bug in what, though? DateTime->today is documented to behave like a
    truncate-to-day operation, which implies setting to 00:00 local time.
    Do you want to change the semantics of truncate? Or make ->today
    cleverer? Or is ->today the wrong approach for this application?
    You could argue it is a bug in the definition of the timezone, but we
    don't really have any control over that, do we? It was pretty
    unexpected to get an exception from this method - I certainly don't want
    to have to wrap all my DateTime calls in a eval just because the
    underlying framework is that unreliable. There has to be a way that the
    today method can ensure it isn't doing anything insane... doesn't there?
    I don't have need for a solution, but I agree with Shane's point. It seems to me that "truncate-to-day" logically means the start of the day which, due to DST rules, does not necessarily mean 00:00:00. The later is a fallacy of non-DST thinking. So if the existing DST rules for a time zone define a day as starting @ 01:00:00, shouldn't a DST intelligent framework such as DateTime treat truncate-to-day routines accordingly?

    Just my 2 cents...

    B
  • Dave Rolsky at Apr 24, 2009 at 8:06 pm

    On Fri, 24 Apr 2009, Metz, Bobby wrote:

    I don't have need for a solution, but I agree with Shane's point.
    It seems to me that "truncate-to-day" logically means the start of the
    day which, due to DST rules, does not necessarily mean 00:00:00. The
    later is a fallacy of non-DST thinking. So if the existing DST rules
    for a time zone define a day as starting @ 01:00:00, shouldn't a DST
    intelligent framework such as DateTime treat truncate-to-day routines
    accordingly?
    The real problem is that there's no date-only class that's part of
    DateTime.

    When someone says "today" they probably don't want "1:00AM", they want
    "2009-02-24" at any time.

    I'm sure that if the behavior were changed so that it found the first
    valid time, someone would come along later and complain about how this is
    weird:

    my $tomorrow = DateTime->today()->add( days => 1 );

    Why is it 1:00 AM?

    Nothing has made me hate date & times as much as working on DateTime ;)


    -dave

    /*============================================================
    http://VegGuide.org http://blog.urth.org
    Your guide to all that's veg House Absolute(ly Pointless)
    ============================================================*/
  • Tatsuhiko Miyagawa at Apr 24, 2009 at 2:50 pm
    I believe it has something to do with the fact that Cairo is
    transitioning to Daylight Savings today.
    On Fri, Apr 24, 2009 at 11:31 PM, Shane McCarron wrote:
    Actually, I was wrong - this is a call to DateTime->today.  As in:

    my $d = DateTime->today(time_zone => "Africa/Cairo") ;

    This is failing with the exception below.  Help?

    Shane McCarron wrote:
    Right now (seconds since the epoch 1240582619 more or less) if I attempt
    to create a datetime object using that value in the Afirca / Caori timezone,
    I am getting an exception:

    //Invalid local time for date in time zone: Africa/Cairo

    Stack:
    [C:\Perl\site\lib\DateTime\TimeZone.pm:209]
    [C:\Perl\site\lib\DateTime\TimeZone.pm:164]
    [C:\Perl\site\lib\DateTime.pm:870]
    [C:\Perl\site\lib\DateTime.pm:335]
    [C:\Perl\site\lib\DateTime.pm:215]
    [C:\Perl\site\lib\DateTime.pm:250]
    [C:\Perl\site\lib\DateTime.pm:1824]
    [C:\Perl\site\lib\DateTime.pm:477]
    //


    I have a customer who is down because of this.  Any suggestions?
    --
    Shane P. McCarron                          Phone: +1 763 786-8160 x120
    Managing Director                            Fax: +1 763 786-8180
    ApTest Minnesota                            Inet: shane@aptest.com



    --
    Tatsuhiko Miyagawa

Related Discussions