On 31 Mar 2014 19:47, "Chris Barker" <chris.bar...@noaa.gov> wrote: > > On Sat, Mar 29, 2014 at 3:08 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On 29 Mar 2014 20:57, "Chris Barker" <chris.bar...@noaa.gov> wrote: >> > I think this is somewhat open for discussion -- yes, it's odd, but in the spirit of practicality beats purity, it seems OK. We could allow any TZ specifier for that matter -- that's kind of how "naive" or "local" timezone (non) handling works -- it's up to the user to make sure that all DTs are in the same timezone. >> >> That isn't how naive timezone handling works in datetime.datetime, though. If you try to mix a timezone (even a Zulu timezone) datetime with a naive datetime, you get an exception. > > fari enough. > > The difference is that datetime.datetime doesn't provide any iso string parsing.
Sure it does. datetime.strptime, with the %z modifier in particular. > The use case I'm imagining is for folks with ISO strings with a Z on the end -- they'll need to deal with pre-parsing the strings to strip off the Z, when it wouldn't change the result. > > Maybe this is an argument for "UTC always" rather than "naive"? Probably it is, but that approach seems a lot harder to extend to proper tz support later, plus being more likely to cause trouble for pandas's proper tz support now. -n
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
