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?
|