[Numpy-discussion] fixing up datetime

Charles R Harris charlesr.harris at gmail.com
Wed Jun 1 17:29:31 EDT 2011


On Wed, Jun 1, 2011 at 3:16 PM, Mark Wiebe <mwwiebe at gmail.com> wrote:

> On Wed, Jun 1, 2011 at 3:52 PM, Charles R Harris <
> charlesr.harris at gmail.com> wrote:
>
>>
>> <snip>
>>
>> Just a quick comment, as this really needs more thought, but time is a bag
>> of worms.
>>
>
> Certainly a bag of worms, I agree.
>
>
>> Trying to represent some standard -- say seconds at the solar system
>> barycenter to account for general relativity -- is something that I think is
>> too complicated and specialized to put into numpy.
>>
>
>>
> Good support for units and delta times is very useful,
>>
>
> This part works fairly well now, except for some questions like what should
> datetime("2011-01-30", "D") + timedelta(1, "M") produce. Maybe "2011-02-28",
> or "2011-03-02"?
>
>
>> but parsing dates and times
>>
>
> I've implemented an almost-ISO 8601 date-time parser.  I had to deviate a
> bit to support years outside the little 10000-year window we use. I think
> supporting more formats could be handled by writing a function which takes
> its date format and outputs ISO 8601 format to feed numpy.
>

Heh, 10000 years is way outside the window in which the Gregorian calender
is useful anyway. Now, strict Julian days start at the creation of the world
so that's a real standard, sort of like degrees Kelvins ;)


>  and handling timezones, daylight savings,
>>
>
> The only timezone to handle is "local", which it looks like standard C has
> a rich enough API for this to be ok.
>
>
>> leap seconds,
>>
>
> This one can be mitigated by referencing TAI or GPS time, I think. POSIX
> time looks like a can of worms though.
>
>
>> business days,
>>
>
> I think Enthought has some interest in a decent business day functionality.
> Some feedback from people doing time series and financial modeling would
> help clarify this though. This link may provide some context:
>
> http://www.financialcalendar.com/Data/Holidays/Formats
>
>
Well, that can change. Likewise, who wants to track ERS for the leap
seconds?

I think the important thing is that the low level support needed to
implement such things is available. A package for common use cases that
serves as an example and that can be extended/modified by others would also
be helpful.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20110601/30086e30/attachment.html>


More information about the NumPy-Discussion mailing list