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.
