parse_datetime() and RFC 9557 suffixes

[Alejandro Colomar]

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