coreutils
coreutils copied to clipboard
`date` behaves differently with no args
date
behaves differently than coreutils when no argument is passed, if the goal of the project is to behave a 100% like the gnu coreutils, this should be fixed. here are two examples , it should be pretty easy to reproduce unless it's a weird problem with both my systems (manjaro and endeavour os)
Exemple 1 :
$./date
Fri Jul 29 09:09:10 2022
$date
$Fri 29 Jul 2022 09:09:12 CEST
Exemple 2 :
$./date
Fri Jul 29 16:40:39 2022
$date
$Fri Jul 29 04:40:40 PM CDT 2022
I looked at the code and i think it's caused by the chrono dependency not correctly detecting the current locale when formatting with %c. not sure about that though.
Could you please replace the screen shot by some text? Screenshots for code are terrible foe accessibility and search
Thanks
done.
I think this is related to this issue https://github.com/chronotope/chrono/issues/708
I’ll work on this one. Would it be okay for this project to use chrono’s unstable-locales
feature?
I'm pretty sure this can be fixed by just changing Format::Default => "%c"
to Format::Default => "%a %b %d %I:%M:%S %Z %p %Y"
in line 351. However, as of now, %Z
does not behave as expected. I already opened an issue https://github.com/chronotope/chrono/issues/749
I don't think it does, this is from after changing to "%a %b %d %I:%M:%S %Z %p %Y"
:
$ LC_ALL=fr_FR.UTF-8 cargo run date
Sat Jul 30 20:38:57 2022
$ LC_ALL=fr_FR.UTF-8 date
sam. 30 juil. 2022 20:39:25 EDT
chrono's format_localized
isn't the same as GNU either though:
$ LC_ALL=en_US.UTF-8 cargo run date
Sat 30 Jul 2022 08:48:56 PM -04:00
$ LC_ALL=en_US.UTF-8 date
Sat Jul 30 08:49:01 PM EDT 2022
It's mostly the same, but pure-rust-locales, which chrono uses for unstable-locales
, differs from GNU date
for some locales.
can we directly call libc ? I have a fix if unsafe code is allowed but obviously it's not ideal
@rayan-mazouz libc
is fine, we call it all throughout the codebase. But if there is a wrapper function in nix
or some cross-platform solution, that would be preferable.
@tertsdiepraam great thanks, my fix works for linux, I'll try to make it work on mac, windows and redox, then do a merge request
I wonder if we can start using icu4x for this. Specifically the icu_datetime
component. Though, it might not be flexible enough yet.
@rayan-mazouz is your fix for linux available on some branch? I'd like to investigate this issue.
sorry, it is not.
There seems to be a workaround to get locale. https://github.com/chronotope/chrono/issues/960#issuecomment-1537353803
I have raised a PR with the above fix: https://github.com/uutils/coreutils/pull/5164