in reply to DateTime::Format::Strptime Parsing Seems to have a Problem?

Appreciate the info... Seems I "couldn't see the forest for the trees" or something, as I was looking for the "12-hour" formatter... but didn't "see" the "%I"...(!)

The final part of the puzzle is to understand how to ensure we can set-up a sequence of datetimes that are 1 day apart. If the mentioned mods are made to the code... and I add some additional code for setting-up a Recurrence, the code becomes:-

use strict; use warnings; #use diagnostics; use DateTime; use DateTime::Format::Strptime; use DateTime::Event::Recurrence; # PART 2 our $LocalTZ = DateTime::TimeZone->new( name => 'local' ); my $dtnow = DateTime->now(time_zone => $LocalTZ); # Current *local* + time printf("\$dtnow: !%s!\n\n", $dtnow); my $lo = "18/03/2019 10:12:53 am"; # Always works my $hi = "24/03/2019 3:15:00 pm"; # Does not work... the format I + need to use # my $hi = "24/03/2019 03:15:00 pm"; # Does not work # my $hi = "24/03/2019 3:15:00 pm"; # Does not work # my $hi = "24/03/2019 15:15:00 pm"; # Works but 15hrs with 'pm' i +s silly # my $hi = "24/03/2019 15:15:00"; # Works my $dmy_fmt = DateTime::Format::Strptime->new( # Let DateTime use 'dd +/mm/yyyy' pattern => '%d/%m/%Y %I:%M:%S %p', # pattern => '%d/%m/%Y %I:%M:%S', # Use this when no 'am/pm' + in the date string # time_zone => 'Australia/Victoria', time_zone => 'local', on_error => 'croak' ); my $lodt = $dmy_fmt->parse_datetime($lo); printf(" \$lodt: !%s!\n", $lodt); my $hidt = $dmy_fmt->parse_datetime($hi); printf(" \$hidt: !%s!\n", $hidt); # ========== PART 2 ========== my $rec1 = DateTime::Event::Recurrence->daily(start => $lodt); # $rec1->set_time_zone('local'); # Doesn't change the 'mis-conversion' my @days = $rec1->as_list( start => $lodt, end => $hidt ); printf("1st Format DAYS:\n"); foreach my $day (@days) { printf(" %s\n", $day->dmy("-")); } printf("\n"); # ---- A different (truncated) format my $strp = DateTime::Format::Strptime->new( pattern => '%d/%m/%Y', time_zone => 'local', on_error => 'croak' ); my $dt1 = $strp->parse_datetime("18/03/2019"); #my $dt1 = $strp->parse_datetime($lo); printf(" \$dt1: !%s!\n", $dt1); my $dt2 = $strp->parse_datetime("24/03/2019"); #my $dt2 = $strp->parse_datetime($hi); printf(" \$dt2: !%s!\n", $dt2); my $rec2 = DateTime::Event::Recurrence->daily(start => $dt1); @days = $rec2->as_list( start => $dt1, end => $dt2 ); printf("2nd Format DAYS:\n"); foreach my $day (@days) { printf(" %s\n", $day->dmy("-")); } printf("\n");

Here, the output is:-

$dtnow: !2019-03-26T15:05:02! $lodt: !2019-03-18T10:12:53! $hidt: !2019-03-24T15:15:00! 1st Format DAYS: 19-03-2019 20-03-2019 21-03-2019 22-03-2019 23-03-2019 24-03-2019 $dt1: !2019-03-18T00:00:00! $dt2: !2019-03-24T00:00:00! 2nd Format DAYS: 18-03-2019 19-03-2019 20-03-2019 21-03-2019 22-03-2019 23-03-2019 24-03-2019

So, it seems DateTime::Format::Strptime is looking at the input strings (which are local times) and converting them according to the 'time_zone' item (which is 'local')... and thus, the resultant objects contain the same time field values.

However, when the recurrence is set-up for the "dd/mm/yyyy hh:mm:ss p"-derived objects, the date is incorrect. I thought it might have to do with the time zone... but setting the time zone on the occurrence made no difference to the dates it came up with.

More confusing, if I set-up a recurrence using the "dd/mm/yyyy"-derived objects, the date is correct, although the time of day is set to 00:00:00 (obviously and reasonably).

So, how does the recurrence using "dd/mm/yyyy hh:mm:ss p"-derived objects need to be configured to display the correct dates, including time of day?

"It's all rather confusing, really...."

Replies are listed 'Best First'.
Re^2: DateTime::Format::Strptime Parsing Seems to have a Problem?
by parv (Parson) on Mar 27, 2019 at 11:55 UTC

    You have not made your code easy enough to test each pair of date-time string & format-to-parse (by using a list of either array references or hash references).

    Do you have issues with both *::Strptime & *::Recurrence? If so, could you please address them in separate threads?

    About *::Strptime output as listed, I do not see anything wrong as far as values of $lodt, $hidt, $dt1, & $dt2 are concerned. What am I missing?

    About *:Recurrence, as I understood the documentation, each event happens at the start of the interval. If it is "daily", then the even will start at 00:00:00. It can be changed to a different time via options of "hours" & "minutes".

    now dt: 2019-03-27T02:46:41 start dt: 2019-03-18T10:12:53 end dt (24/03/2019 3:15:00 pm) : 2019-03-24T15:15:00 end dt (24/03/2019 03:15:00 pm) : 2019-03-24T15:15:00 end dt (24/03/2019 15:15:00 pm) : 2019-03-24T15:15:00 end dt (24/03/2019 15:15:00) : 2019-03-24T15:15:00 Recurring event at 11:23 from 2019-03-18T10:12:53 to 2019-03-24T15:15: +00 ... !! 2019-03-18T11:23:00 !! 2019-03-19T11:23:00 !! 2019-03-20T11:23:00 !! 2019-03-21T11:23:00 !! 2019-03-22T11:23:00 !! 2019-03-23T11:23:00 !! 2019-03-24T11:23:00

      Thanks for your thoughts, parv ...and granted, my code was a bit 'off' and could have made the comparisons clearer.

      Still, after looking at what we've covered, I'd say DateTime::Format::Strptime is doing what's expected -- it was more about how I (mis-)understood how the routine works (but see the bottom of this post).

      ...but the problem with 'Recurrence' is still not explained (well enough), to my thinking. To quote the docs:-

      "If no parameters are given, then the set members each occur at the be +ginning of the specified recurrence. For example, by default, the monthly() method returns a set containin +g the first day of each month. Without parameters, the weekly() method returns a set containing Mond +ays...."

      Unfortunately, we have no example in the docs for the 'daily' method we're looking at. Therefore, we can only assume that the 'daily' method gives us a set where each element (each repeat) begins at '00:00:00', as parv suggested... so we'll test that out. Note that as we're testing the 'beginning of the specified recurrence' note in the docs, we should follow what the docs declare and ensure "no parameters are given" -- hence, we'll modify parv's line of code from:-

      my $day_ev = DateTime::Event::Recurrence->daily( 'hours' => $hour , 'm +inutes' => $min );

      ...to be instead:-

      my $day_ev = DateTime::Event::Recurrence->daily;

      Doing so and running parv's code with no other modifications gives the following output:-

      now dt: 2019-03-30T23:41:09 start dt: 2019-03-18T10:12:53 end dt (24/03/2019 3:15:00 pm) : 2019-03-24T15:15:00 end dt (24/03/2019 03:15:00 pm) : 2019-03-24T15:15:00 end dt (24/03/2019 15:15:00 pm) : 2019-03-24T15:15:00 end dt (24/03/2019 15:15:00) : 2019-03-24T15:15:00 Recurring event at 11:23 from 2019-03-18T10:12:53 to 2019-03-24T15:15: +00 ... !! 2019-03-19T00:00:00 !! 2019-03-20T00:00:00 !! 2019-03-21T00:00:00 !! 2019-03-22T00:00:00 !! 2019-03-23T00:00:00 !! 2019-03-24T00:00:00

      ...showing the same error - the start of the period is '00:00:00' as we expected (hoped)... but the date is still wrong.

      Therefore, there appears to be something wrong with either our assumption of the 'beginning' of a 'daily' recurrence being '00:00:00' ...OR... there is a fault in the Recurrence code when 'no parameters are given'.

      I lean more to there being a fault in the Recurrence code, as if you change the 'hours' and 'minutes' parameters to '0' in the 'as_list()' method in parv's original code, the same error in date occurs.

      The other thing of interest is that if the DateTime::Format::Strptime usage includes a pattern that is only "%d/%m/%Y" and the string dates are specified to match, we still get the '00:00:00' beginning times on each element of the Recurrence set... but the date is correct -- this is what I did in the first modifications I made to the code in my original posting.

      Edit 31-Mar-2019 00:42 UTC: Something else that may be relevant here: The section "Floating DateTimes" in the DateTime module docs includes the comment:

      If you are planning to use any objects with a real time zone, it is strongly recommended that you do not mix these with floating datetimes.

      ...which would indicate we need to include a 'time zone' parameter at every call to a DateTime method... maybe?

      Any other thoughts?

        no longer applicable: Your font may be lying to you for you had referenced some account named p-a-r-y in your reply instead of p-a-r-v with lowercase-V (if you were referring to my reply).

        Case of using default of 0 hours & 0 minutes as the time of the recurring event: If the time has already passed (Mar 18 0:0a) before the start of recurring event period (Mar 18 10:12a to Mar 24 3:15p), then including Mar 18 as one of the dates of the recurring event will be erroneous.