Re: parse_datetime() and RFC 9557 suffixes

[Paul Eggert]

The whole business of time zone offsets is a mess.

First, it's not clear whether ISO 8601 requires ":" in numeric time zone 
offsets. RFC 3339 Appendix A suggests it's not.

Second, in practice the colon often is omitted; it's certainly omitted 
by POSIX and ISO C strftime %z, by the Time Zone Database, and by lots 
of other places - this is partly due to the influence of RFC 5322 and 
its predecessors and related standards, all of which omit the colon. The 
Time Zone Database and many other sources also commonly used offsets 
that contain just hours, e.g., "+02", which I think conforms to ISO 8601 
(hard to tell, since ISO 8601 is not freely readable).

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.)

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".

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.