On Wed, Aug 19, 2015 at 1:30 PM, Carl Meyer <[email protected]> wrote:
> > I don't have the official $300+ PDF of the standard neither do I :-( > , but wikipedia > > disagrees with you: > > <https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators>. > > I think Chris is distinguishing between "timezones" and "UTC offsets". > ISO 8601 can certainly encode a UTC offset, but it can't encode a > timezone in the sense of "America/New_York". > exactly. However, the Wikipedia page does say: "Time zones <https://en.wikipedia.org/wiki/Time_zone> in ISO 8601 are represented as local time (with the location unspecified), as UTC <https://en.wikipedia.org/wiki/UTC>, or as an offset from UTC." but nothing about how one specifies the location -- I have no idea if there is an ISO 8601 way to specify a location, but I've never seen it -- wikipedia may mean that it should be specified some other way than embedded in the string. but it's not reliable to reverse-engineer and offset to find the timezone. though I don't think this really has anything to do with the topic at ahnd -- is anyone proposing that parsing ISO strings _should_ assume a time zone? BTW, an ISO string without an offset (or z, or...) is often (officially) called "local time". So numpy's datetime takes that to mean the timezone of the machine's locale settings -- which is a really ugly mess, so let's not do that. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [email protected]
_______________________________________________ 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/
