For whatever it's worth glibc strptime on linux does *not* in fact accept +HH:MM, and if it is passed, it silently interprets, say, -05:30 as -05 (and :30 remains in the string for subsequent directives to consume). Testing with an offset with zero minutes at the end of the string does not account for this, which may be why some people in the bug comments reported that it did support it.
Interesting. I was mostly suggesting it would be supported based on the man page, which specifies an RFC-822/ISO 8601 standard timezone specification. Since ISO-8601 includes both HHMM and HH:MM (and indeed that what is generated by .isoformat()), based on their man page it would seem they intend to support this. This is either a bug in glibc, a bug in their documentation, or I'm misinterpreting the "slash" to mean "the intersection of timezone offset specifiers laid out in RFC-822 and ISO-8601" rather than "the union of timezone offset specifiers laid out in RFC-822 and ISO-8601". Might be worth opening a bug on glibc to clarify.
Just to be clear, date accepts them on input through date -d (which does not use strptime or posix getdate, but its own internal parse_datetime function)
Yes, no matter how it's implemented, I was just suggesting that %:z is not an extension plucked out of thin air (though I did not know about the `date` behavior and %:z *was* my immediate suggestion for an extension, so at the very least it doesn't violate principle of least surprise), but rather has some precedent in widely used datetime software.