On Fri, Jun 10, 2011 at 10:03 AM, Bruce Southey <[email protected]> wrote:
> ** > <snip> > > I have following the multiple date/time discussions with some interest as > it is clear there is not 'one way' (perhaps it's Dutch). But, I do keep > coming back to Chris's concepts of time as a strict unit of measure and time > as a calender. So I do think that types of changes are rather premature > without defining a some base measurement of time - probably some thing like > Unix time or International Atomic Time (TAI) but not UTC due to leap seconds > (http://en.wikipedia.org/wiki/Leap_second). > I think this is an important issue, definitely. I proposed an idea for dealing with it here: http://mail.scipy.org/pipermail/numpy-discussion/2011-June/056660.html where I got some feedback that using UTC by default would have enough compatibility issues to change it to POSIX time by default with a TAI mode selectable in the metadata. Leap seconds make using UTC rather problematic for a couple of reasons: > 1) It's essentially only historical. A range of the seconds in December > 2011 computed 'now' in June 2011 using UTC might be different than a range > calculated in a couple weeks if leaps seconds are added to December 2011. > 2) There is also the issue that 23:59:60 December 31, 2008 UTC is a valid > time but not for other years like 2009 and 2010. It also means that you have > to be careful of doing experiments that require accuracy of seconds or less > because a 1 second gap could be recorded as a 2 second gap. > With the TAI datetime metadata it should be possible to deal with these problems in a way. By specifying times further than 6 months in the future in TAI, the leap-second issue can be avoided for 1), and leap seconds like 2) and time differences around them will work with TAI. The conversion from TAI datetimes to/from UTC strings would include the :60 for added leap seconds. > The other issue is how do you define the np.arange step argument since that > can be in different scales such as month, years, seconds? Can a user > specific days and get half-days (like 1.5 days) or must these be 'integer' > days? > The datetime and timedelta are purely integers, so half-days are only possible by going to hours. I think this is good for datetime, but for timedelta it would be nicer to have a general physical quantities/units system in NumPy, so timedelta would be a regular integer or float with time as its metadata instead of having a timedelta type. That's a whole lot more work though, and doesn't seem like a short term thing... Cheers, Mark > > Bruce > > _______________________________________________ > NumPy-Discussion mailing list > [email protected] > http://mail.scipy.org/mailman/listinfo/numpy-discussion > >
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
