[Numpy-discussion] timezones and datetime64

[Chris Barker - NOAA Federal]

Thanks all for taking an interest. I need to think a bot more about
the options before commenting more, but:

while we're at it:

It seems very odd to me that datetime64 supports different units
(right down to  attosecond) but not different epochs. How can it
possible be useful to use nanoseconds, etc, but only right around
1970? For that matter, why all the units at all? I can see the need
for nanosecond resolution, but not without changing the epoch -- so if
the epoch is fixed, why bother with different units? Using days (for
instance) rather than seconds doesn't save memory, as we're always
using 64 bits. It can't be common to need more than 2.9e12 years (OK,
that's not quite as old as the universe, so some cosmologists may need
it...)

Personally, I never need finer resolution than seconds, nor more than
a century, so it's no big deal to me, but just wondering....

-Chris

On Wed, Apr 3, 2013 at 4:27 PM, Pauli Virtanen <pav at iki.fi> wrote:
> Mark Wiebe <mwwiebe <at> gmail.com> writes:
>> It seems to me that adding a time zone to the datetime64
>> metadata might be a good idea, and then allowing it to be
>> None to behave like the Python naive datetimes.
>
> Probably also TAI and UTC/Posix.
>
> Converting from one format to the other is problematic since
> all of them (except TAI afaik) require looking things up in
> regularly updated databases. Not only restricted to conversions,
> but also arithmetic, `b - a`. Affects also UTC/Posix via leap
> seconds --- this probably doesn't usually matter, but if we want
> to be strict, it's not good to ignore the issue.
>
> On the string representation level, one possible way to go
> could be to require UTC markers for UTC times, and disallow
> them for local times::
>
>     datetimeutc64('2013-02-02T03:00:00')      # -> exception
>     datetimeutc64('2013-02-02T03:00:00Z')     # -> valid
>     datetimeutc64('2013-02-02T03:00:00-0200') # -> valid
>     datetime64('2013-02-02T03:00:00')         # -> valid
>     datetime64('2013-02-02T03:00:00Z')        # -> exception
>     datetime64('2013-02-02T03:00:00-0200')    # -> exception
>
> Dealing with actual TZ handling could be left to be the
> responsibility of the users, maybe with some helper conversion
> functions on the Numpy side.
>
> This still leaves open the question how leap seconds should be
> handled, or if we should just ignore the results and let
> people live with
> datetime64('2012-01-01T00:00:00Z') - datetime64('1970-01-01T00:00:00Z')
> being wrong by ~ 30 seconds...
>
> --
> Pauli Virtanen
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



-- 

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.Barker at noaa.gov