On 31 Mar 2014 19:47, "Chris Barker" <chris.barker@noaa.gov> wrote:
>
> On Sat, Mar 29, 2014 at 3:08 PM, Nathaniel Smith <njs@pobox.com> wrote:
>>
>> On 29 Mar 2014 20:57, "Chris Barker" <chris.barker@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