For a date in ISO 8601 extended format with "Difference between local
time and UTC of day" (§4.2.5.1), the timezone can be written only as
±hh:mm or ±hh.

§4.3.3d says (http://dotat.at/tmp/ISO_8601-2004_E.pdf#):
"the expression shall either be completely in basic format, in which
case the minimum number of separators necessary for the required
expression is used, or completely in extended format, in which case
additional separators shall be used in accordance with 4.1 and 4.2."

strftime should be able to output the timezone with a colon so a
compliant date could be produced without post-processing, and so a
locale could default to an ISO 8601 date and time format (other than
basic format).  Perhaps a new flag could be used, e.g. "%:z".

A way to output ±hh if mm==00, or ±hh:mm otherwise, may be useful too.
Maybe "%3z" or "%:3z" ("unspecified" per SUSv4: "a minimum field width
is specified for any conversion specifier other than C, F, G, or Y").

- Michael

    %z     +hhmm numeric time zone (e.g., -0400)
    %:z    +hh:mm numeric time zone (e.g., -04:00)
    %::z   +hh:mm:ss numeric time zone (e.g., -04:00:00)
    %:::z  numeric time zone with : to necessary precision
           (e.g., -04, +05:30)

It reimplements strftime to do so.

Incidentally, I came here to report precisely this (strftime(3) and date(1)
not consistent wrt. GNU extensions). I’ve since added %-d and %:z to MirBSD
libc’s strftime(3) — whose date(1) uses that.

I’ve noticed that trying to use %:z in a locale category fails, but passing
it directly to date(1) works:

$ LC_TIME=de_DE.UTF-8 date +"$(LC_TIME=de_DE.UTF-8@iso8601 locale d_t_fmt)"
2021-04-04T21:34:31+02:00 (CEST), 2021-W13-7 (So)
$ LC_TIME=de_DE.UTF-8@iso8601 date +%c
2021-04-04T21:34:35%:z (CEST), 2021-W13-7 (So)

I thought I could get by with using "%Y-%m-%dT%H:%M:%S%z (%Z), %G-W%V-%u (%a)"
but the OP makes a good point that mixing basic and extended formats is not
permitted either.

Please forward this upstream so it’ll be implemented. Thanks!