On Thu, Mar 20, 2014 at 5:53 PM, Alexander Belopolsky
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@noaa.gov