Re: parse_datetime() and RFC 9557 suffixes

[Alejandro Colomar]

Hi Paul, Bruno,

On Thu, Aug 01, 2024 at 03:10:29PM GMT, Paul Eggert wrote:
> The whole business of time zone offsets is a mess.

:)

> Third, RFC 9557 does not allow either "2023-09-20[+02:00]" or
> "2023-09-20[+0200]". It requires a time before the timezone. (This issue is
> minor; I've already mentioned this to Alejandro, so he knows what he's
> proposing is not standardized by ISO or by the RFC.)

The ABNF says it's not valid, because of

        date-time-ext = date-time suffix

which clearly says the suffix is to be applied after a date-time, which
is defined by RFC 3339::5.6 as

        date-time       = full-date "T" full-time

However, I'd say that's more likely to be that the authors of RFC 9557
didn't think of dates without time (maybe they didn't think of a case
where this would be useful), rather than having expressely desired to
not include it in their standard.  And so, let's say this is a tasteful
extension to RFC 9557.  :)

> Fourth, RFC 9557 section 1.2 strongly discourages suffixes like "[+02:00]".
> That suffix means clocks never change in that location, which is
> historically inaccurate everywhere. Instead, you're supposed to use a suffix
> like "[Africa/Tripoli]". I view this as a major objection to Alejandro's
> proposal for the output of "passwd".

We could use the location suffix in passwd.  I thought the numeric
offset would be more compact, though.  I had expected that %Z would
produce the full time-zone name instead of the abbreviation (I hadn't
experimented with it).

However, strftime(3)'s %Z produces "CEST" in my system $now, which is
a time-zone abbreviation (not a time-zone name), and so I'm not sure if
it would be a valid RFC 9557 time-zone-name.  I don't see an easy way to
produce the time zone name with strftime(3), which would complicate
things.  (Although I'm already extending the standard, so let's say
an abbreviation is good for going into a suffix.)

So, yeah, let's use %Z instead of %z.  It's also compact, it seems.

> It might make sense to extend parse-datetime (and GNU date -d) to parse RFC
> 9557 [time-zone] suffixes, should they become popular. That should be
> doable. It might also be nice to extend strftime (and therefore GNU date
> +FMT) to generate them, though that'd be a bit harder since the info is not
> always easily available.
> 
> However, none of this should be needed for the 'passwd' command. For that,
> it's probably better just to stick with its current output, which is just a
> date without time zone.

It's not strictly necessary, as we don't use gnulib, but users might
complain that passwd(1) produces invalid dates.  Especially if any of
them is passing it in a script to date(1).

In general, as Unix programs are designed to be chained together with
pipes, I would be cautious of producing output in a program which no
other program can understand.

Which means, I think I'll keep the current behavior of no time-zone info
at the moment, and if you add support for it in gnulib (and thus
date(1)) at some point, I'll propose it for shadow too.

Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

signature.asc
Description: PGP signature