> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
