My first impression on BusinessDays is that it's a brute force, first cut solution. For a small range of days it's probably just fine, but over several years performance is going to take a hit because every day in the range gets evaluated and every evaluation considers the entire set of holidays for a computational complexity of O(days-in-range*holidays-in-set). Days in range is bound to be a much larger set than the set of holidays in that same range, so it could be improved by chopping the range into three parts, the from-week, the to-week, and everything in between. The in-between set automatically has two non-business days per week that you don't have to enumerate day by day. Then you address the business days in the endpoint weeks and subtract the holidays in the range. Likewise, every full year will have a set of holidays that are guaranteed to land on a weekday (by fiat), so those are automatically out. Conditional ones, like New Years Day (which don't result in a holiday when it occurs on the weekend still have to be enumerated, but if you're covering a really large span of years, you can count on the fact that (I think) there are only 28 unique years, so you if you are covering a span of centuries, you can execute a middle and endpoint strategy there too, though it's quite a bit messier than figuring New Years Days holidays.
On Thursday, January 28, 2016 at 8:19:41 AM UTC-8, Tom Breloff wrote: > > Also check out Ito.jl and TimeZones.jl. It seems that both Ito.jl and > BusinessDays.jl are geared towards bond trading, so I'm not sure how well > they work for general queries. If you find you have opinions about the > strengths/weaknesses of any of these packages, please post here! > > On Thu, Jan 28, 2016 at 10:16 AM, Michael Landis <darksky...@gmail.com > <javascript:>> wrote: > >> Wow, I will give that a try. Thank you! >> >> On Thursday, January 28, 2016 at 6:52:38 AM UTC-8, Michael Landis wrote: >>> >>> Maybe I'm missing something, but the one thing I want from DateTime is >>> the ability to determine whether a day has elapsed since a file modify >>> date, but not just a calendar day... at least a business day (i.e. >>> Saturdays and Sundays don't count), but even better if a calendar could >>> skip past government and/or business holidays too, so elapsed days are only >>> the meaningful ones, weekends and business holidays would not increment a >>> business days elapsed counter. >>> >>> For example, if you have downloaded daily closing stock prices at 8PM on >>> Friday the 29th of January, there's no point in downloading them again >>> until after the close of trading Monday, February 1st, but if you >>> originally downloaded them at 2PM on Friday the 29th of January, you will >>> get one more result by downloading them again at 8PM that same day. It >>> gets even more interesting when you throw time zone into the mix. The >>> markets are still actively trading at 6:30 PM Pacific Time. Need DateTime >>> functions that will aid in making those decisions. Is this being >>> considered for Julia and if not, should it be? >>> >> >
