in reply to problems parsing Time/Date strings

any sugestions?

:) About what?

I don't know, and I believe most programmers don't, what the correct return value is supposed to be

I get

1341719704 1341690904
which doesn't mean much to me either way, it also doesn't match what DateTime (supposed to be more accurate ) has to say
perl -le " use DateTime; print DateTime->new(qw{ month 7 day 7 hour 20 + minute 55 second 04 year 2012 time_zone GMT } )->epoch(); " 1341694504
perl -le " use DateTime; print DateTime->new(qw/ month 7 day 7 hour 20 + minute 55 second 04 year 2012 time_zone CET / )->epoch(); " 1341687304

Replies are listed 'Best First'.
Re^2: problems parsing Time/Date strings
by vlad_tepesch (Acolyte) on Jul 08, 2012 at 21:11 UTC

    thank you

    your second result seems to be CEST (-7200 to GMT). does the DateTime automaticly use DST iif the date is within the DST-timespan?
    that is also a bit weird because not all CET-Countries may habe DST or am i wrong?

    it seems that Date::Parse uses the local time zone then parsing unknwon dates. since iam in CEST the results i got are plausible.

    i would consider this behaviour as a bug since the local time zone has nothing to do with the dates to parse.

      I would definitely recommend DateTime. It is well done and actively maintained. You can set your locale or use time_zone => 'floating' to ignore time zones. I would also take a look at the slides from Dave Rolsky's DateTime talk (video here). They are handy for understanding why weird things happen with date math.

        Thanks for the links !

        I totally agree about the slide comment regarding DateTime::Duration

        Luckily DateTime::Format::Human::Duration works around that

        #!/usr/bin/perl -- use strict; use warnings; use DateTime::Duration; use DateTime::Format::Human::Duration; use DateTime::Format::Natural; @ARGV = ( "last week", "today" ) unless @ARGV; my $dfn = DateTime::Format::Natural->new; my $start = $dfn->parse_datetime(shift); my $end = $dfn->parse_datetime(shift); my $diff = $end - $start; print "$end - $start = ", DateTime::Format::Human::Duration->new->format_duration($diff), "\n" +; __END__ 2012-08-04T00:00:00 - 2012-07-28T00:00:00 = 1 week

      DateTime automatically uses DST, but only if your date is in a timezone that observes daylight savings.

      use 5.010; use DateTime; use DateTime::Format::Strptime; # Choose a datetime in the southern summer. my $later = DateTime->now(time_zone => 'UTC')->add(months => 6); # Choose an output format that includes time zone. $later->set_formatter(DateTime::Format::Strptime->new(pattern => '%F % +T %z')); # An abstract time zone; no daylight savings. say "UTC+10: ", $later->clone->set_time_zone('+1000'); # Queensland, Australia does not observe daylight savings. say "Brisbane: ", $later->clone->set_time_zone('Australia/Brisbane'); # But New South Wales does! say "Sydney: ", $later->clone->set_time_zone('Australia/Sydney');
      perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'

      DateTime automaticly use DST iif the date is within the DST-timespan?

      Yes, I think so. See How does DST affect day length?

      that is also a bit weird because not all CET-Countries may habe DST or am i wrong?

      Don't know , don't care, its why I use DateTime. I think this is why you can specify timezone by country ( DateTime::TimeZone:: ) since DST is political concept and DateTime gets this information via olsondb

      use DateTime; my $tz = DateTime::TimeZone->new(qw{ name CET }); printf "%20s %s\n", $_, $tz->$_ for qw/ is_floating is_utc has_dst_changes is_olson name category +/; __END__ is_floating 0 is_utc 0 has_dst_changes 54 is_olson 1 name CET category CET

      Which is the CET you want?

      i would consider this behaviour as a bug since the local time zone has nothing to do with the dates to parse.

      I wouldn't, maybe it needs more explicit mention in the docs, but as a default it does make sense as much as any value (like GMT).

      OTOH, I would consider the real bug to be vague timestamps :)

      All CET countries use daylight saving, so the results look to be correct. If the function takes no account of what the actual time is, what use is it?

        "All CET countries use daylight saving"

        Algeria and Tunisia use CET but do not observe daylight saving.

        "If the function takes no account of what the actual time is, what use is it?"

        What function?

        Update: in case anyone doubts me and tries to claim that Algeria uses West Africa Time, not Central European Time, then note that Wikipedia backs me up, as does DateTime...

        $ perl -MDateTime -E'say "$_: ", DateTime->now->set_time_zone($_)->str +ftime("%F %T %Z (%z)") for @ARGV' Europe/Paris Africa/Algiers Africa/ +Tunis Africa/Lagos Europe/Paris: 2012-07-09 16:21:06 CEST (+0200) Africa/Algiers: 2012-07-09 15:21:06 CET (+0100) Africa/Tunis: 2012-07-09 15:21:06 CET (+0100) Africa/Lagos: 2012-07-09 15:21:06 WAT (+0100)
        perl -E'sub Monkey::do{say$_,for@_,do{($monkey=[caller(0)]->[3])=~s{::}{ }and$monkey}}"Monkey say"->Monkey::do'