The date you give doesn't seem to conform to any format ParseDate recognizes. See VALID-DATE-FORMATS of Date::Manip::Date for valid formats. In particular passing a string rather than a number and replacing the '.' with 'T' or a space or just removing it probably does what you want:
use Date::Manip;
my $result = ParseDate('20231024 020045');
print $result;
Prints:
2023102402:00:45
Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond
| [reply]
[d/l]
[select] |
Both of the earlier replies are correct. Your string does not match any of the date formats that Date::Manip recognizes... except for one. In this case, you parsed a delta since you included a valid number. What you ended up parsing is:
ParseDate("in 20231024.020045 seconds")
which turns out to be a bit more than 7 months from now.
As previously suggested, if you turn the period into a 'T' (20231024T020045) it will match a common ISO 8601 format and give you the result you want. | [reply] |
Time difference, interesting.
I was thinking that that would be parsed as Unix epoch second, but obviously not.
On a second thought, "20230909" would then not be parsed as a date in Sep 2023. Oh well
| [reply] |
As I was adding all of the different things that I wanted Date::Manip to parse, I parsed all of the ways that I could find to specify a date. But then I wanted to be able to parse "in 2 hours" as a date, which implied a date calculation of (NOW + 2 hours). So, after all of the standard date formats are tried (and fail), I pass the value to the delta parsing routine which will catch all of the expected delta formats (like 'in 2 hours'). The downside (if you can call it that) is that ANY number can be parsed as a number of seconds (and that's what has happened here).
It's unexpected... but it's also why, if you're parsing a date, you need to be somewhat familiar with the formats that Date::Manip knows about. It'll handle just about every date format imaginable, but you still have to be aware of the formats, otherwise an unexpected result can occur when you parse a format you didn't expect.
| [reply] |
20231024.020045
Ah, I see you're a person of culture as well! To be sure, is that date-time in "YYYYMMDD.HMnS" (see Date::Manip::Date) or "%Y%m%d.%H%M%S" format? If not, rest of it is useless.
I did not find in Date::Manip::Date documentation anything matching your example. OTOH 20231024 is parsed to date of Oct 24, 2023 as expected.
I also did not see a way, perhaps missed, to convert the return value of Date::Manip::Date->parse_format( q[%Y%m%D\.%H%M%S], q[20231024.020045] ) into Date::Manip::Obj.
| [reply]
[d/l]
[select] |