[Numpy-discussion] fixing up datetime
Mon Jun 6 09:45:51 CDT 2011
On Mon, Jun 6, 2011 at 4:43 AM, Wes McKinney <email@example.com> wrote:
> On Mon, Jun 6, 2011 at 8:16 AM, Mark Dickinson <firstname.lastname@example.org>
> > On Thu, Jun 2, 2011 at 5:42 PM, Mark Wiebe <email@example.com> wrote:
> >> Leap years are easy compared with leap seconds. Leap seconds involve a
> >> hardcoded table of particular leap-seconds that are added or subtracted,
> >> are specified roughly 6 months in advance of when they happen by
> >> the International Earth Rotation and Reference Systems Service (IERS).
> >> POSIX time_t doesn't store leap seconds, so if you subtract two time_t
> >> values you may get the wrong answer by up to 34 seconds (or 24, I'm not
> >> totally clear on the initial 10 second jump that happened somewhere).
> > Times in the future would be hairy, too. If leap seconds are
> > supported, how many seconds are there in the timedelta:
> > 2015-01-01 00:00:00 - 2010-01-01 00:00:00
> > ? Is it acceptable for the result of the subtraction like this to
> > change when the leap second table is updated (e.g., to reflect a newly
> > added leap second on June 30th, 2012)?
> > Mark
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion@scipy.org
> > http://mail.scipy.org/mailman/listinfo/numpy-discussion
> Tangential to the technical details being discussed, but my $0.02 on
> datetime generally:
> One thing I tried to do in pandas is enable the implementation of
> custom time deltas ("date offsets" in pandas parlance). For example,
> let's say add 5 weekdays (or business days) to a particular date. Now,
> there are some arbitrary choices you have to make, e.g. what do you do
> when the date being added to is not a business day? If you look in
> you can see some examples. Things are a bit of a mess in places but
> the key ideas are there. One nice thing about this framework is that
> you can create subclasses of DateOffset that connect to some external
> source of information, e.g. trading exchange information-- so if you
> want to shift by "trading days" for that exchange-- e.g. include
> holidays and other closures, you can do that relatively seamlessly.
> Downside is that it's fairly slow generally speaking.
> I'm hopeful that the datetime64 dtype will enable scikits.timeseries
> and pandas to consolidate much ofir the datetime / frequency code.
> scikits.timeseries has a ton of great stuff for generating dates with
> all the standard fixed frequencies.
I'm wondering if removing the business-day unit from datetime64, and adding
a business-day API would be a good approach to support all the things that
are needed? Any time you add regular days to a business date, you need to
resolve the result to NaT or the closest business day earlier or later, so
having that always go through an "add_to_business_date" function with a
variety of keyword parameters, and various other API functions, might be
better in general.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion