[Numpy-discussion] code review for datetime arange
Fri Jun 10 17:57:49 CDT 2011
On Fri, Jun 10, 2011 at 10:03 AM, Bruce Southey <email@example.com> wrote:
> 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
I think this is an important issue, definitely. I proposed an idea for
dealing with it here:
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
> 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'
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...
> NumPy-Discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion