Repository navigation
[C++][R] strptime fails to parse with %b or %B on Windows #31816
Description
Activity
Rok Mihevc / @rok:
A relevant c++ test would in scalar_string_test.cc would be:StrptimeOptions options("%Y %B %d", TimeUnit::SECOND, /*error_is_null=*/false); this->CheckUnary("strptime", R"(["2021 September 13"])", timestamp(TimeUnit::SECOND), R"(["2021-09-13"])", &options);
Rok Mihevc / @rok:
This could be a locale issue. We also noticed this behaviour on a windows machine with:LC_TIME=English_United States.1252
Dragoș Moldovan-Grünfeld / @dragosmg:
Thetest-dplyr-funcs-datetime.Rfile where the unit test failing on the CI mentioned in the ticket description forcesLC_TIMEto be"C".
Snippet:# base::strptime() defaults to local timezone # but arrow's strptime defaults to UTC. # So that tests are consistent, set the local timezone to UTC # TODO: consider reevaluating this workaround after ARROW-12980 withr::local_timezone("UTC") if (tolower(Sys.info()[["sysname"]]) == "windows") { withr::local_locale(LC_TIME = "C") }
PR #50146 (primarily about CSV date/time parsing) includes a fix for this: the vendored musl
strptimeused on Windows compiles out all name-based specifiers becausenl_langinfo()is unavailable there. The PR adds static C-locale name tables, making%b/%B(and%a/%A/%h) parse on Windows, case-insensitively, matching musl's C-locale behavior on Linux. Validated on Windows CI (MinGW CLANG64/MINGW64, MSVC Python wheel, RTools, MATLAB, and ARM64 MSVC). The issue's reproducer ("2021 September 13"with"%Y %B %d") parses with that change.
The following works on macOS
but fails on Windows, with:
#> Error: Invalid: Failed to parse string: '2021 September 13' as a scalar of type timestamp[s]I came across this while implementing the
parse_date_time()bindings, when the Windows CI jobs were failing to parse date with the months expressed either as name or short name. https://github.com/apache/arrow/runs/6270529412?check_suite_focus=true#step:20:20856Reporter: Dragoș Moldovan-Grünfeld / @dragosmg
Watchers: Rok Mihevc / @rok
Related issues:
Note: This issue was originally created as ARROW-16443. Please see the migration documentation for further details.