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