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. 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"? -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 chris.bar...@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
