On Fri May 08 17:43:19 2015, ESAYM wrote:
Show quoted text> Since the call to the native libc strptime was removed in 1.17, that
> appears to have broken parsing dates in anything other than English.
> Output from attached script ran on a linux system with MX locale set:
>
> Version 1.29:
> 1.29
> vie may 8 16:00:19 CDT 2015
> vie, 08 may 2015 16:00:19
> Error parsing time at /home/user/perl5/lib/perl5/x86_64-linux-gnu-
> thread-multi/Time/Piece.pm line 469.
>
> Version 1.10:
> 1.10
> vie may 8 16:01:56 CDT 2015
> vie, 08 may 2015 16:01:56
> vie, 08 may 2015 16:01:56
My first knee jerk reaction to this was to restore the native call to strptime(). However, Windows platforms don't have strptime().
The next obvious solution is to correctly populate the lc_time_T struct (in Piece.xs) using a native function call. However, the structs and functions to work on them seem to be different on Linux, Mac, and Win.
Curious with how other languages with strptime() type functions handle this, I went and dug through the source code of PHP, Python, and Ruby.
PHP seems to be all native calls to strptime() and strftime() with warnings about using these functions on Windows platforms. Ruby touted that strptime() and strftime() were "platform independent". Looking at the source it indeed uses its own home brewed functions including hardcoded English day and month names that can't be changed. Python was a little different. It touts both strftime() and strptime() to be locale dependent. On a closer look at the source, it seems for its datetime modules, it pre-populates a month name and day name array by starting at a known date and iterating through a week's worth of day names (by calling native strftime(%A)) and then a years worth of month names (by calling native strftime(%B)).
I am going to attempt sometime similar to the python way for handling locales in Time::Piece. I think it is a worthy cause to have Time::Piece to be able to print and parse dates in a user's current locale.
