On Sun, Mar 10, 2019 at 04:16:37PM -0400, Ted Unangst wrote: > Hiltjo Posthuma wrote: > > 2. The military/nautical UTC offsets are also reversed. This was also > > actually > > a bug in RFC822: > > > > RFC5322 (referenced in strptime(3) man page): > > https://tools.ietf.org/html/rfc5322 > > Section 4.3, page 34 says: > > " > > The 1 character military time zones were defined in a non-standard > > way in [RFC0822] and are therefore unpredictable in their meaning. > > The original definitions of the military zones "A" through "I" are > > equivalent to "+0100" through "+0900", respectively; "K", "L", and > > "M" are equivalent to "+1000", "+1100", and "+1200", respectively; > > "N" through "Y" are equivalent to "-0100" through "-1200". > > respectively; and "Z" is equivalent to "+0000". However, because of > > the error in [RFC0822], they SHOULD all be considered equivalent to > > "-0000" unless there is out-of-band information confirming their > > meaning. > > " > > > > While comparing the other BSD and Linux code-bases I noticed NetBSD has > > fixed > > this on 2017-08-24. It is not in NetBSD 8 stable yet, but in NetBSD-current: > > http://cvsweb.netbsd.org/bsdweb.cgi/src/lib/libc/time/strptime.c > > So the fix doesn't follow either RFC? Does anyone implement the 5322 suggested > behavior of all zero offsets?
Afaik no implementation uses zero offsets for military zones, but most implementations do return NULL when parsing a military zone with strptime(3) %z. Not all BSD man pages reference the same RFCs, like RFC5322. The OpenBSD strptime(3) man page (%z) describes military/nautical zones are supported. - NetBSD supports it (correctly since only a few months ago and it is not in stable or backported). - FreeBSD and DragonFlyBSD do not support them (strptime returns NULL). - Linux glibc does not support them (strptime returns NULL). - Linux musl libc does not support %z. Any comments/OKs for the other points (1, 3, 4) ? Thanks for the review, -- Kind regards, Hiltjo
