On Thu, Mar 20, 2014 at 5:53 PM, Alexander Belopolsky <ndar...@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.bar...@noaa.gov
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
