coreutils icon indicating copy to clipboard operation
coreutils copied to clipboard

`date` behaves differently with no args

Open rayan-mazouz opened this issue 2 years ago • 12 comments

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 :

image $./date Fri Jul 29 09:09:10 2022 $date $Fri 29 Jul 2022 09:09:12 CEST


Exemple 2 :

image $./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.

rayan-mazouz avatar Jul 29 '22 07:07 rayan-mazouz

Could you please replace the screen shot by some text? Screenshots for code are terrible foe accessibility and search

Thanks

sylvestre avatar Jul 29 '22 16:07 sylvestre

done.

I think this is related to this issue https://github.com/chronotope/chrono/issues/708

rayan-mazouz avatar Jul 29 '22 19:07 rayan-mazouz

I’ll work on this one. Would it be okay for this project to use chrono’s unstable-locales feature?

Stonks3141 avatar Jul 30 '22 18:07 Stonks3141

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

s1gse9v avatar Jul 30 '22 21:07 s1gse9v

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

Stonks3141 avatar Jul 31 '22 00:07 Stonks3141

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.

Stonks3141 avatar Jul 31 '22 00:07 Stonks3141

can we directly call libc ? I have a fix if unsafe code is allowed but obviously it's not ideal

rayan-mazouz avatar Jul 31 '22 04:07 rayan-mazouz

@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 avatar Jul 31 '22 06:07 tertsdiepraam

@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

rayan-mazouz avatar Jul 31 '22 09:07 rayan-mazouz

I wonder if we can start using icu4x for this. Specifically the icu_datetime component. Though, it might not be flexible enough yet.

tertsdiepraam avatar Aug 03 '22 08:08 tertsdiepraam

@rayan-mazouz is your fix for linux available on some branch? I'd like to investigate this issue.

Ecordonnier avatar Feb 06 '23 10:02 Ecordonnier

sorry, it is not.

rayan-mazouz avatar Feb 12 '23 22:02 rayan-mazouz

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

KrishnaNagam avatar Aug 15 '23 15:08 KrishnaNagam