I have the following Perl code:
print Time::Piece->strptime("2023:01:01 00:00:00.000", "%Y:%m:%d %H:%M:%S")->strftime("%Y:%m:%d %H:%M:%S") . "\n";
print Time::Piece->strptime("2023:01:02 00:00:00", "%Y:%m:%d %H:%M:%S%z")->strftime("%Y:%m:%d %H:%M:%S") . "\n";
print Time::Piece->strptime("2023:01:03 00:00", "%Y:%m:%d %H:%M:%S")->strftime("%Y:%m:%d %H:%M:%S") . "\n";
It has the following output:
Garbage at end of string in strptime: .000 at C:/Perl64/lib/Time/Piece.pm line 581.
Perhaps a format flag did not match the actual input? at C:/Perl64/lib/Time/Piece.pm line 581.
2023:01:01 00:00:00
2023:01:02 00:00:00
2023:01:03 00:00:00
As you can see, in the first call strptime complained about the input string. However, in the second and third calls, strptime did not complain about the fact that the input string had missing values. It just assumed that the time zone offset (%z) for the second call was +0000, and that the seconds (%S) for the third call was 00.
According to the Time::Piece module documentation, the strptime() function comes from FreeBSD. I looked at the FreeBSD man page for strptime, and there is no mention of what the behavior should be with missing values in the input string.
I am running ActivePerl on Windows, but can I assume that I would see the same behavior (no complaints and assuming 0 for any missing values) on a different OS or a different flavor of Perl (e.g. Strawberry Perl)?
Looking at Time::Piece's implementation of the underlying
strptime, one of two things happens when it comes to incomplete string, depending on the first conversion that lacked data.For some, an error (
NULL) is returned. Time::Piece croaks when this happens. It's not relevant to this question.For those of interest, parsing ends with the unprovided members of
timeptrleft untouched, as if they weren't provided in the format.So we need to look at how Time::Piece calls this function for the defaults. This is how it initializes the structure:
So yes, the hour, minute and second values default to zero.
Keep in mind the the final result might not be zero for conversions that default to zero because it's possible to specify a date-time that doesn't exist. In such circumstances, Linux rounds up to the nearest valid time.