Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

date: add military time zone support #2618

Open
jfinkels opened this issue Aug 29, 2021 · 1 comment
Open

date: add military time zone support #2618

jfinkels opened this issue Aug 29, 2021 · 1 comment
Labels

Comments

@jfinkels
Copy link
Collaborator

In GNU date version 8.32,

$ date --version | head -n 1
date (GNU coreutils) 8.32.199-88562
$ date -u -d "05:00C" +%T
02:00:00

The time zones labeled "A", "B", "C", etc. are UTC+1, UTC+2, UTC+3, etc. and these are called military time zones in RFC 5322. (In earlier versions of GNU date, it appears there was a bug in this behavior, so using version 8.32 or later is important: https://lists.gnu.org/r/bug-gnulib/2019-08/msg00005.html )

But uutils doesn't support this:

$ ./target/debug/coreutils date -u -d "05:00C" +%T
date: invalid date '05:00C'

This is because it relies on the chrono crate for parsing, and chrono doesn't support military time zones. Here is the test case that demonstrates it: https://github.com/chronotope/chrono/blob/3467172c31188006147585f6ed3727629d642fed/src/format/parse.rs#L759 Here is the relevant section of RFC 5322, Section 4.3:

The 1 character military time zones were defined in a non-standard
way in [RFC822] and are therefore unpredictable in their meaning.
The original definitions of the military zones "A" through "I" are
equivalent to "+0100" through "+0900" respectively; "K", "L", and "M"
are equivalent to "+1000", "+1100", and "+1200" respectively; "N"
through "Y" are equivalent to "-0100" through "-1200" respectively;
and "Z" is equivalent to "+0000". However, because of the error in
[RFC822], they SHOULD all be considered equivalent to "-0000" unless
there is out-of-band information confirming their meaning.

@stale
Copy link

stale bot commented Jan 13, 2023

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the wontfix label Jan 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants