date(locale): fix hardcoded formats with nl_langinfo(D_T_FMT)#9756
Merged
sylvestre merged 1 commit intouutils:mainfrom Dec 23, 2025
Merged
date(locale): fix hardcoded formats with nl_langinfo(D_T_FMT)#9756sylvestre merged 1 commit intouutils:mainfrom
sylvestre merged 1 commit intouutils:mainfrom
Conversation
naoNao89
changed the title
naoNao89
force-pushed
the
test/date-locale-tests
branch
from
bf9778c to
4c0695d
Compare
sylvestre
reviewed
Dec 20, 2025
naoNao89
force-pushed
the
test/date-locale-tests
branch
2 times, most recently
from
d8a7568 to
5155ed1
Compare
sylvestre
reviewed
Dec 20, 2025
|
|
||
| #[test] | ||
| #[cfg(unix)] | ||
| fn test_date_locale_format_structure() { |
Contributor
There was a problem hiding this comment.
can we have another tests with french as locale? thanks
Contributor
Author
There was a problem hiding this comment.
added test_date_locale_fr_french
Contributor
There was a problem hiding this comment.
nice
but i was also thinking about the day & month in french
naoNao89
force-pushed
the
test/date-locale-tests
branch
from
5155ed1 to
119ede1
Compare
Replace hardcoded format string selection with direct nl_langinfo(D_T_FMT) usage. This ensures locale-specific formatting details (leading zeros, component ordering, hour formats) are properly respected from system locale data instead of detecting 12/24-hour preference and returning hardcoded alternatives. Changes to locale.rs: - Remove detect_12_hour_format() and uses_12_hour_format() - Simplify get_locale_default_format() to use D_T_FMT directly - Add timezone injection if %Z missing from locale format - Add use nix::libc import Add test coverage (tests/by-util/test_date.rs): - 4 new unit tests for locale format structure validation - 7 new integration tests verifying locale-specific behavior - Tests prevent regression to hardcoded format strings Addresses feedback from PR uutils#9654 comment #3676971020
naoNao89
force-pushed
the
test/date-locale-tests
branch
from
119ede1 to
a85255c
Compare
|
The output will still be slightly different. We want |
Contributor
Author
|
hmm macOS does support |
|
GNU testsuite comparison: |
Contributor
Author
|
https://man7.org/linux/man-pages/man3/nl_langinfo.3.html https://github.com/lattera/glibc/blob/master/locale/langinfo.h#L232 |
|
Even though the test is passing, this is still incorrect: |
Contributor
|
bizarre, on my system: date (GNU coreutils) 9.7 rust: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #9654
where we used hardcoded format strings. Now we grab the actual locale format from
nl_langinfo(D_T_FMT).Verified
# Test case from comment #3676971020 $ LC_ALL=en_US.UTF-8 date -u -d 2025-12-14T1:00Main branch (PR #9654):
GNU coreutils:
$ LC_ALL=en_US.UTF-8 gdate -u -d 2025-12-14T1:00 Sun Dec 14 01:00:00 UTC 2025 # Has leading zeroOur fix (test/date-locale-tests):
Test 2: nl_NL.UTF-8
Addresses #9654 comment