date -d"@1690466034" isn't supported

[sylvestre]

with GNU:

$ LANG=C /usr/bin/date -d"@1690466034"
Thu Jul 27 15:53:54 CEST 2023

with our:

$ date -d"@1690466034"
date: invalid date '@1690466034'

[tertsdiepraam]

Just to point people in the right direction: this should probably be fixed in parse_datetime

[philolo1]

@sylvestre @tertsdiepraam I would like to work on this.

[philolo1]

After some investigation, i think "@" is just the number of seconds and the GNU date uses parse-datetime https://github.com/coreutils/gnulib/blob/master/lib/parse-datetime.y#L597

[BFostek]

@philolo1, I'm debugging here as well.
The code uses parse_datetime::from_str(...) that doesn't parse "@1690466034",
but parse_datetime::parse_datetime::from_str(...) does.

[philolo1]

@BFostek @tertsdiepraam @sylvestre
If we use parse_datetime::parse_datetime::from_str we would not be able to parse relative time, i think we need to use both in this pr.

[philolo1]

@BFostek @tertsdiepraam @sylvestre
#5181

I just did a pull request. I think there are some other improvements that could be made, but i would prefer to do it in a different pr. For example my ubunto gnu also support negative unix timestamps like "@-2". Would it be appropiate to create a new issue for this?

[apatrushev]

It is not an invalid date already, but it is not the same yet

$ LANG=C /usr/bin/date -d"@1690466034"
Thu Jul 27 13:53:54 UTC 2023
$ coreutils date -d"@1690466034"
Thu Jul 27 13:53:54 2023

[KrishnaNagam]

Currently date until doesn't print Time zone abbreviations. It should be fixed once this PR is merged #5164.

[kov]

@sylvestre I believe this issue has been fixed (probably by the work done by @philolo1 on parse_datetime?):

kov@jabuticaba ~/P/c/s/u/date (main)> LC_TIME=C /usr/bin/date -d"@-1690466034"
Wed Jun  7 07:06:06 -03 1916
kov@jabuticaba ~/P/c/s/u/date (main)> LC_TIME=C cargo run -- -d"@-1690466034"
<snip>
Wed Jun  7 07:06:06 1916