On Mon, Jun 6, 2011 at 4:43 AM, Wes McKinney <[email protected]> wrote:
> On Mon, Jun 6, 2011 at 8:16 AM, Mark Dickinson <[email protected]> > wrote: > > On Thu, Jun 2, 2011 at 5:42 PM, Mark Wiebe <[email protected]> wrote: > >> Leap years are easy compared with leap seconds. Leap seconds involve a > >> hardcoded table of particular leap-seconds that are added or subtracted, > and > >> are specified roughly 6 months in advance of when they happen by > >> the International Earth Rotation and Reference Systems Service (IERS). > The > >> 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 > > [email protected] > > 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 > > https://github.com/wesm/pandas/blob/master/pandas/core/datetools.py > > 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. -Mark
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
