in reply to Date::Manip returns wrong value

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.

Replies are listed 'Best First'.
Re^2: Date::Manip returns wrong value
by parv (Parson) on Nov 02, 2023 at 19:50 UTC

    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

      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.