[Numpy-discussion] Dates and times and Datetime64 (again)

[Chris Barker]

On Thu, Mar 20, 2014 at 5:53 PM, Alexander Belopolsky <ndarray at mac.com>wrote:

> I recall that it was at some point suggested that epoch be part of dtype.
>  I was not able to find the reasons for a rejection,
>

I don't think it was rejected, it just wasn't adopted by anyone to write a
NEP and write the code...

I actually think it's silly to allow changing the units without changing
the epoch. But the pre-defined epoch works fine for all my use cass, so I'm
not going to push that. I also did think it was a separate issue that
timezones, and thus shouldn't clutter up the NEP (though one someone is
opening the code, it would be a good time to do it..)

but it would make perfect sense to keep timezone offset in dtype and treat
> it effectively as an alternative epoch.
>

Hmm -- good point -- if we had a dynamic epoch you could just sift that to
account for the time zone offset. Though I think that's
an implementation issue.

The way I like to think about datetime is that YYYY-MM-DD hh:mm:ss.nnn is
> just a fancy way to represent numbers which is more convoluted than decimal
> notation, but conceptually not so different.  So different units, epochs or
> timezones are just different ways to convert an abstract notion of a point
> in time to a specific series of bits inside an array.  This is what dtype
> is for - a description of how abstract numbers are stored in memory.
>

yes -- and also how to convert to/from other types -- which is where the
trick is here.

-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.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140321/887f25b5/attachment.html>