Hi Paul, As reported earlier today in <https://lists.sr.ht/~hallyn/shadow/%3Cmzbl4gkns5nyt7otg4t7cxlds2q64wutpjnngxpnix55ocbds2@whvswk343dwl%3E> parse_datetime() cannot handle the suffix specified in RFC 9557.
$ date --date='2023-09-20[+0200]'
date: invalid date ‘2023-09-20[+0200]’
$ date --version | head -n1
date (GNU coreutils) 9.4
(GNU coreutils uses gnulib for parsing the date.)
This suffix is useful for denoting that a date is not UTC, but local
time, keeping the date string free of spaces, while still respecting the
relevant standards.
This date format has been proposed by me (after a suggestion from Paul
that I look into RFC 9557 suffixes) in shadow utils, to reduce
inconsistencies in date handling.
In the latest release of shadow utils, passwd(1) prints (using UTC):
$ passwd -S alx
alx P 2023-09-20 0 99999 7 -1
which resulted in confusion to users, since we use local time sometimes,
and UTC time some other times. A bug was reported here:
<https://github.com/shadow-maint/shadow/issues/1057>. To close that bug
report, in git HEAD, we've changed the behavior to print using local
time:
$ sudo ./src/passwd -S alx
alx P 2023-09-21 0 99999 7 -1
And the proposal of adding a timezone indication would help explain that
difference. However, the space-separated fields match the contents of
/etc/shadow, so we cannot use "2023-09-21 +0200", since it would break
existing scripts (assuming those exist, which is a possibility). Using
an RFC 9557 suffix allows us to add the timezone information without
adding whitespace, in a standardeese way.
$ sudo ./src/passwd -S alx
alx P 2023-09-21[+0200] 0 99999 7 -1
It would be good if this format was also understood by date(1), and thus
by gnulib's date/time-parsing functions.
Have a lovely night!
Alex
--
<https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
