Before I consider it a bug, I want to make sure the issue is not on my side or in my understanding. This is part of the reason my sample code attempted to go from object to string and back to object-to test both the strftime() and strptime() methods.
My C is quite rusty (and I haven't dug around inside the perl source tree before), but it appears the process goes as follows when looking at the perl-5.30.3 source on MetaCPAN (PLEASE CORRECT ME IF YOU SPOT ANY ERRORS BELOW):
- When Time::Piece->strptime($time_string, $format_string) (found in cpan/Time::Piece/Piece.pm in the source distribution) is called, the format is first parsed by Time::Piece->_translate_format($format, $strptime_trans_map) . $strptime_trans_map appears to only contain the content of $trans_map_common (which defines formats 'c', 'r', and 'X', and NOT the formats 'e', 'D', 'F', 'R', 's', 'T', 'u', 'V', 'x', 'z', or 'Z', from $strftime_trans_map ).
- _strptime($string, $format, $islocal, $locales) (found in cpan/Time::Piece/Piece.xs) is then called. There are two such functions in Piece.xs:
- line 345: static char * _strptime( pTHX_ const char buf*,
const char *fmt,
struct tm *tm,
int *gotGMT )
- line 1025: void _strptime ( string,
format,
got_GMT,
SV* localization )
Based on the signature, it appears the second (on line 1025) is called. After loading the locale data structure via _cpopulate_c_time_locale(aTHX_ locales ), this version of _strptime calls the version on line 345 as remainder = (char *)_strptime(aTHX_ string, format, &mytm, &gotGMT). If this returns with anything other than a '\0', either an "Error parsing time" or "Garbage at end of string in strptime:" message is returned.
- In _strptime( string, format, islocal, locales ) (to use the names from the original calls), when the "Z" character is found it appears to seek the end of the time zone name, then calls my_tzset(aTHX). According to perlguts, aTHX is an (a)rgument (TH)ingy(X).
- According to the comments, my_tzset(pTHX) ((p)rototype (TH)ingy(X)) is a wrapper to tzset() designed to make it work better on Win32. It does so by way of two #IFDEFs that determine if fix_win32_tzenv() is called. As my test failed on a Linux system, I do not believe the #IFDEFs are involved. tzset() (I believe from the system time.h) is then called.
Questions:
- Are there any (obvious?) flaws in my tracing of the logic above?
- If indeed it is a bug (can someone confirm?), is it a problem with perl, or with a library used while compiling perl?
Thank you for your time and attention. Stay safe!
