Hello, I'm trying to exclude a business day, any week, from a trading calendar.

Lets say I don't want to trade on any Friday, what I'm doing is changing the weekmask:

class CustomCalendar(IEPAExchangeCalendar):
    def __init__(self):
        super().__init__()

    @property
    def weekmask(self):
       return '111000'

custom_calendar = CustomCalendar()

but I'm getting:

ValueError: Special dates [Timestamp('1992-07-03 17:00:00+0000', tz='UTC'), ..., ...] are not trading days.

What is the best way to exclude business day every week?

#61

In the Brazilian calendar, Ash Wednesday is a half day, starting trading at 1pm. [1]

I noticed it's already implemented, but with it's currently commented and have a TODO tag. [2]

Judging by the same feature being implemented here, I guess the code can now be commented out, right?

Hello, I am working on building a conda package for our library, and it uses trading_calendars. I'm having a hard time building my own version of the conda package for trading_calendars due to some odd dependency issues. Do you have any plans to add this project to Quantopian's conda channel? I'm hoping that you'll be able to avoid some of the issues I was running into and that I'll just be able to pull your package when it's on there.

previous_session_label requires that the date you pass actually be a session.

We should have an equivalent that takes any date and a calendar and passes back the session occurring prior to that date. Vague pseudo-code:

def last_valid_session(dt, exch='NYSE'):    
    cal = tc.get_calendar(exch)
    if cal.is_session(date):
        return cal.previous_session_label(dt)
    else:
        while not cal.is_session(dt):
            dt = dt-1
        return dt

In line with the comment in the CME calendar code, CME products sometimes have their own unique hours. Eg,

• /ZC. Sunday – Friday, 7:00 p.m. – 7:45 a.m. CT and Monday – Friday, 8:30 a.m. – 1:20 p.m. CT. https://www.cmegroup.com/trading/why-futures/welcome-to-corn-futures.html

• /M6E. Sunday - Friday 5:00 p.m. - 4:00 p.m. CT with a 60-minute break each day beginning at 4:00 p.m. CT. https://www.cmegroup.com/trading/fx/e-micros/e-micro-euro_contract_specifications.html

Is there a pattern for creating instrument specific calendars?

According to the news, the original Spring Festival holiday is until January 30, 2020 (the sixth day), and the normal opening trading time is January 31, 2020 (the seventh day). Today, the regulatory level issued a notice that the stock and futures exchanges were closed on January 31, and the market opened as usual on February 3. The A-share market opening time is delayed by 1 day.

below codes is my Revise，the business logc is ok after adding a date as '2020-01-31' to XSHG array:
df = exchange_calendar_xshg.precomputed_shanghai_holidays
exchange_calendar_xshg.precomputed_shanghai_holidays = df.insert(0, pd.Timestamp(2020, 1, 31))
trading_calendar = get_calendar("XSHG")

the original code can be found from: https://github.com/quantopian/trading_calendars/blob/master/trading_calendars/exchange_calendar_xshg.py

This comment on incorrect dates for pandas_market_calendars also applies to trading_calendars, these days show as holiday in TC when they are not:

rsheftel/pandas_market_calendars#116

Australian holidays are only accurate back to 2010. This PR will extend the Australian Securities Exchange holiday calendar back to 1992.

I see that the earliest starting date for the NYSE (XNYS) calendar is 1990-01-01 and from that date onwards the trading_calendars and pandas_market_calendars implementation are the same. But prior to that date there are many changes in the holiday calendar that pcal has that trading_calendars does not. If you are OK, I would suggest bringing over the pre-1990 holidays.

These holidays were added by @pldrouin in rsheftel/pandas_market_calendars#30. He was nice enough to upload a csv of all the holidays in the /tests/data/nyse_all_full_day_holidays_since_1928.csv and the results can be verified here: http://s3.amazonaws.com/armstrongeconomics-wp/2013/07/NYSE-Closings.pdf

Example:

trading_calendars:

from .us_holidays import (
    USNewYearsDay,
    USMartinLutherKingJrAfter1998,
    USMemorialDay,
    USIndependenceDay,
    Christmas,
    MonTuesThursBeforeIndependenceDay,
    FridayAfterIndependenceDayExcept2013and2019,
    USBlackFridayBefore1993,
    USBlackFridayInOrAfter1993,
    September11Closings,
    HurricaneSandyClosings,
    HurricaneGloriaClosing,
    NewYorkBlackout,
    PresidentialElectionDays,
    USNationalDaysofMourning,
    ChristmasEveBefore1993,
    ChristmasEveInOrAfter1993,
)

pandas_market_calendars

def regular_holidays(self):
       return AbstractHolidayCalendar(rules=[
           USNewYearsDay,
           USMartinLutherKingJrAfter1998,
           USLincolnsBirthDayBefore1954,
           USWashingtonsBirthDayBefore1964,
           USWashingtonsBirthDay1964to1970,
           USPresidentsDay,
           GoodFriday,
           USMemorialDayBefore1964,
           USMemorialDay1964to1969,
           USMemorialDay,
           USIndependenceDayBefore1954,
           USIndependenceDay,
           USLaborDay,
           USThanksgivingDayBefore1939,
           USThanksgivingDay1939to1941,
           USThanksgivingDay,
           USElectionDay1848to1967,
           USElectionDay1968to1980,
           USVeteransDay1934to1953,
           USColumbusDayBefore1954,
           ChristmasBefore1954,
           Christmas,
       ])

I'm pretty sure the timezone for XTS should be America/Toronto instead of Canada/Atlantic:

Hi,

Currently Im trying to make a own custom calendar, which needs to have multiple break in a single trading day.

So far as I drilled the source code, seems the current calendar implementation dont support a break during a single trading day, as each day can only have a record in the 'schedule' variable with a single 'market_open' and 'market_close'.

So may I ask if there is any idea on how to implement this? or any other approaches I can do?

The NYSE calendar sets its time zone to "US/Eastern" as opposed to "America/New_York". According to wikipedia, IANA, the provider of the time zone information behind ptyz, considers "US/Eastern" to be depricated. I believe the US/Eastern maps to America/New_York in the pytz package, but for completeness you may want to consider switching to America/New_York.

https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

from trading_calendars import get_calendar
get_calendar('CME')

Raises TypeError: data is already tz-aware UTC, unable to set specified tz: UTC.

This is a result of this issue in pandas where 'UTC' and pytz.UTC are not considered equal (I'm seeing this in pandas version 0.24.0).

I believe the fix would be to change the return in trading_calendars.trading_calendar.scheduled_special_times():

return pd.Series(
        index=pd.DatetimeIndex(days, tz='UTC'),
        data=days_at_time(days, time, tz=tz),
)

to:

return pd.Series(
        index=pd.DatetimeIndex(days, tz=pytz.UTC),
        data=days_at_time(days, time, tz=tz),
)

(Basically, replace 'UTC' with pytz.UTC when creating the index.)

https://www.cmegroup.com/tools-information/holiday-calendar.html
Memorial Day seems not in CMES regular holidays. Can we fix it?

import trading_calendars as tc

def scheduled_special_times(calendar, start, end, time, tz):
    days = calendar.holidays(start, end)
    return pd.Series(
        index=pd.DatetimeIndex(days, tz=pytz.UTC),
        data=tc.trading_calendar.days_at_time(days, time, tz=tz),
)
tc.trading_calendar.scheduled_special_times = scheduled_special_times

cal_cme = tc.get_calendar('CMES')
schedule = cal_cme.schedule```

`schedule['2019-05-20':'2019-05-30']`
	market_open	market_close
2019-05-20 00:00:00+00:00	2019-05-19 22:01:00	2019-05-20 22:00:00
2019-05-21 00:00:00+00:00	2019-05-20 22:01:00	2019-05-21 22:00:00
2019-05-22 00:00:00+00:00	2019-05-21 22:01:00	2019-05-22 22:00:00
2019-05-23 00:00:00+00:00	2019-05-22 22:01:00	2019-05-23 22:00:00
2019-05-24 00:00:00+00:00	2019-05-23 22:01:00	2019-05-24 22:00:00
**2019-05-27 00:00:00+00:00	2019-05-26 22:01:00	2019-05-27 17:00:00**
2019-05-28 00:00:00+00:00	2019-05-27 22:01:00	2019-05-28 22:00:00
2019-05-29 00:00:00+00:00	2019-05-28 22:01:00	2019-05-29 22:00:00
2019-05-30 00:00:00+00:00	2019-05-29 22:01:00	2019-05-30 22:00:00



`schedule['2020-05-20':'2020-05-30']`

market_open	market_close
2020-05-20 00:00:00+00:00	2020-05-19 22:01:00	2020-05-20 22:00:00
2020-05-21 00:00:00+00:00	2020-05-20 22:01:00	2020-05-21 22:00:00
2020-05-22 00:00:00+00:00	2020-05-21 22:01:00	2020-05-22 22:00:00
**2020-05-25 00:00:00+00:00	2020-05-24 22:01:00	2020-05-25 17:00:00**
2020-05-26 00:00:00+00:00	2020-05-25 22:01:00	2020-05-26 22:00:00
2020-05-27 00:00:00+00:00	2020-05-26 22:01:00	2020-05-27 22:00:00
2020-05-28 00:00:00+00:00	2020-05-27 22:01:00	2020-05-28 22:00:00
2020-05-29 00:00:00+00:00	2020-05-28 22:01:00	2020-05-29 22:00:00

Calling get_calendar('XNYS').previous_session_label(datetime.date(2020, 2, 29)) raises a KeyError.

2019-05-02 and 2019-05-03 are labor's day holidays(addition holiday only this year) in china, not trading day

Builds with
Python: 3.5, PANDAS_VERSION=0.18.1 NUMPY_VERSION=1.11.3
fail on travis (linux 64) because conda is unable to resolve dependencies.

https://travis-ci.org/quantopian/trading_calendars/jobs/554823104

We added the holidays, but I did not port the tests over yet: #169.

Todo for the future.

There have been some changes to this library that is not part of a release. Do you plan to make a new release soon?

Related to the issue: quantopian/zipline#2700

As @richafrank mentioned on the issue linked above is the module-level variable start_default in trading_calendars\trading_calendar.py being '1990-01-01'.

In my opinion '1990-01-01' seems somewhat arbitrary. As far as my understanding goes, the only reason it is '1990-01-01' and not earlier is to avoid caches to take up too much memory.

Disadvantages of this approach:

• The open-issue linked above
• PrecomputedTradingCalendar uses its own start/end dates and some of them start earlier than '1990-01-01'
• The cached data frame does not take that much memory anyway? (but I might be utterly wrong here)

Possible solutions off the top of my head:

• Change 'start_default' to something much earlier
• Add exchange specific start_default and end_default, this is consistent with how PrecomputedTradingCalendar behaves
• Add a way for end-user to change start_default and end_default (e.g. store start_default and end_default in a mutable container than give access to end-user).

And on to nose2 or pytest

17-04-2019 is holiday(no trading day) add it to the trading calendar

Python 3.8 test crash:

...
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/agil/.pyenv/trading_calendars/lib/python3.8/site-packages/nose/failure.py", line 39, in runTest
    raise self.exc_val.with_traceback(self.tb)
  File "/home/agil/.pyenv/trading_calendars/lib/python3.8/site-packages/nose/loader.py", line 417, in loadTestsFromName
    module = self.importer.importFromPath(
  File "/home/agil/.pyenv/trading_calendars/lib/python3.8/site-packages/nose/importer.py", line 47, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "/home/agil/.pyenv/trading_calendars/lib/python3.8/site-packages/nose/importer.py", line 94, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "/home/agil/.pyenv/trading_calendars/lib/python3.8/imp.py", line 234, in load_module
    return load_source(name, filename, file)
  File "/home/agil/.pyenv/trading_calendars/lib/python3.8/imp.py", line 171, in load_source
    module = _load(spec)
  File "<frozen importlib._bootstrap>", line 702, in _load
  File "<frozen importlib._bootstrap>", line 671, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 783, in exec_module
  File "<frozen importlib._bootstrap>", line 219, in _call_with_frames_removed
  File "/home/agil/trading_calendars/tests/test_xwbo_calendar.py", line 5, in <module>
    from .test_trading_calendar import ExchangeCalendarTestBase
  File "/home/agil/trading_calendars/tests/test_trading_calendar.py", line 33, in <module>
    from trading_calendars.errors import (
  File "/home/agil/trading_calendars/trading_calendars/__init__.py", line 16, in <module>
    from .trading_calendar import TradingCalendar
  File "/home/agil/trading_calendars/trading_calendars/trading_calendar.py", line 86, in <module>
    class TradingCalendar(with_metaclass(ABCMeta)):
  File "/home/agil/trading_calendars/trading_calendars/trading_calendar.py", line 830, in TradingCalendar
    def minute_to_session_label(self, dt, direction="next"):
  File "/home/agil/trading_calendars/trading_calendars/utils/preprocess.py", line 115, in _decorator
    return _build_preprocessed_function(
  File "/home/agil/trading_calendars/trading_calendars/utils/preprocess.py", line 252, in _build_preprocessed_function
    new_func.__code__ = CodeType(*map(getitem(args), _code_argorder))
TypeError: an integer is required (got type bytes)

[error] 100.00% nose.failure.Failure.runTest: 0.0001s
----------------------------------------------------------------------
Ran 52 tests in 0.024s

FAILED (errors=52)

CodeType was updated and now require a new argument posonlyargcount:

• https://bugs.python.org/issue36886

As the title suggests, there is always a minor failures in all calendar test tests\test_XXXX_calendar.py for all exchange code XXXX

For example, running nosetests tests\test_xnys_calendar.py yields

[success] 49.38% tests.test_xnys_calendar.XNYSCalendarTestCase.test_minute_to_session_label: 7.4921s
[success] 12.18% tests.test_xnys_calendar.XNYSCalendarTestCase.test_open_and_close_for_session: 1.8481s
[success] 11.56% tests.test_xnys_calendar.XNYSCalendarTestCase.test_next_prev_open_close: 1.7531s
[success] 11.36% tests.test_xnys_calendar.XNYSCalendarTestCase.test_next_prev_minute: 1.7233s
[success] 3.56% tests.test_xnys_calendar.XNYSCalendarTestCase.test_minute_index_to_session_labels_0: 0.5395s
[success] 3.05% tests.test_xnys_calendar.XNYSCalendarTestCase.test_next_prev_session: 0.4620s
[success] 2.26% tests.test_xnys_calendar.XNYSCalendarTestCase.test_sanity_check_session_lengths: 0.3434s
[success] 1.79% tests.test_xnys_calendar.XNYSCalendarTestCase.test_minute_index_to_session_labels_2: 0.2719s
[success] 1.78% tests.test_xnys_calendar.XNYSCalendarTestCase.test_is_open_on_minute: 0.2705s
[success] 1.73% tests.test_xnys_calendar.XNYSCalendarTestCase.test_minute_index_to_session_labels_1: 0.2623s
[success] 0.94% tests.test_xnys_calendar.XNYSCalendarTestCase.test_start_end: 0.1422s
[fail] 0.12% tests.test_xnys_calendar.XNYSCalendarTestCase.test_session_closes_in_range: 0.0187s
[success] 0.06% tests.test_xnys_calendar.XNYSCalendarTestCase.test_minutes_for_period: 0.0096s
[fail] 0.05% tests.test_xnys_calendar.XNYSCalendarTestCase.test_session_opens_in_range: 0.0069s
[success] 0.04% tests.test_xnys_calendar.XNYSCalendarTestCase.test_minutes_in_range: 0.0054s

Ran 27 tests in 15.773s

FAILED (failures=2)

This is a follow up to #113

Setting up the required packages to run the tests for the first time was a hassle for me. It's probably a good idea to add test dependencies to setup.py to make it easier for us to contribute.

Dependencies:
nose
nose-ignore-docstring
nose-timer
nose-parameterized

When creating a new calendar, a FutureWarning is generated. pandas version used is 0.24.1.

us_calendar = get_calendar('XNYS')

gives:

/usr/lib/python3.7/site-packages/pandas/core/sorting.py:257: FutureWarning: Converting timezone-aware DatetimeArray to timezone-naive ndarray with 'datetime64[ns]' dtype. In the future, this will return an ndarray with 'object' dtype where each element is a 'pandas.Timestamp' with the correct 'tz'.
To accept the future behavior, pass 'dtype=object'.
To keep the old behavior, pass 'dtype="datetime64[ns]"'.
items = np.asanyarray(items)
/usr/lib/python3.7/site-packages/pandas/core/sorting.py:257: FutureWarning: Converting timezone-aware DatetimeArray to timezone-naive ndarray with 'datetime64[ns]' dtype. In the future, this will return an ndarray with 'object' dtype where each element is a 'pandas.Timestamp' with the correct 'tz'.
To accept the future behavior, pass 'dtype=object'.
To keep the old behavior, pass 'dtype="datetime64[ns]"'.
items = np.asanyarray(items)

I noticed that the load time for most all calendars are around 1.5 seconds, except the XTKS calendar which takes 12.2 seconds to load. Is there any particular reason for that?

This is the code and results I used:

from datetime import datetime
import trading_calendars as tc

def load_times():
    for name in tc.calendar_utils._default_calendar_factories:
        print(name, end='')
        start = datetime.now()
        _ = mcal.get_calendar(name)
        end = datetime.now()
        print(f': run time is {end - start}')

ASEX: run time is 0:00:01.462395
BVMF: run time is 0:00:01.608703
CMES: run time is 0:00:01.247221
IEPA: run time is 0:00:01.221055
XAMS: run time is 0:00:01.239995
XASX: run time is 0:00:01.405535
XBKK: run time is 0:00:01.483120
XBOG: run time is 0:00:01.902455
XBOM: run time is 0:00:00.635975
XBRU: run time is 0:00:01.259231
XBUD: run time is 0:00:01.545929
XBUE: run time is 0:00:01.647241
XCBF: run time is 0:00:01.397777
XCSE: run time is 0:00:01.523843
XDUB: run time is 0:00:01.301222
XFRA: run time is 0:00:01.396143
XHEL: run time is 0:00:01.423694
XHKG: run time is 0:00:01.365153
XICE: run time is 0:00:01.561660
XIDX: run time is 0:00:01.219812
XIST: run time is 0:00:01.244760
XJSE: run time is 0:00:01.435470
XKAR: run time is 0:00:01.075075
XKLS: run time is 0:00:01.191726
XKRX: run time is 0:00:00.940299
XLIM: run time is 0:00:01.465012
XLIS: run time is 0:00:01.357335
XLON: run time is 0:00:01.407390
XMAD: run time is 0:00:01.282585
XMEX: run time is 0:00:01.377445
XMIL: run time is 0:00:01.336494
XMOS: run time is 0:00:01.307830
XNYS: run time is 0:00:01.408174
XNZE: run time is 0:00:01.423343
XOSL: run time is 0:00:01.464810
XPAR: run time is 0:00:01.283910
XPHS: run time is 0:00:01.333504
XPRA: run time is 0:00:01.456183
XSES: run time is 0:00:00.961805
XSGO: run time is 0:00:01.739328
XSHG: run time is 0:00:00.709314
XSTO: run time is 0:00:01.572027
XSWX: run time is 0:00:01.435308
XTAI: run time is 0:00:01.137340
XTKS: run time is 0:00:12.211477
XTSE: run time is 0:00:01.481504
XWAR: run time is 0:00:01.544426
XWBO: run time is 0:00:01.442748
us_futures: run time is 0:00:00.859409
24/7: run time is 0:00:01.463259
24/5: run time is 0:00:01.034509

At the moment, creating any custom calendar that has an open or close during the hour of Daylight Savings time changes will throw an AmbiguousTimeError:

from datetime import time
from pytz import timezone
from trading_calendars.exchange_calendar_cmes import CMESExchangeCalendar


class TestCal(CMESExchangeCalendar):
    
    name = 'TestCal'
    
    tz = timezone('America/Chicago')

    open_times = (
        (None, time(1, 1)),
    )
    
TestCal()

---------------------------------------------------------------------------
AmbiguousTimeError                        Traceback (most recent call last)
<ipython-input-7-746e7f5c6750> in <module>
     14     )
     15 
---> 16 TestCal()

~\.conda\envs\proj_ortz\lib\site-packages\trading_calendars\trading_calendar.py in __init__(self, start, end)
    109 
    110         # `DatetimeIndex`s of standard opens/closes for each day.
--> 111         self._opens = _group_times(
    112             _all_days,
    113             self.open_times,

~\.conda\envs\proj_ortz\lib\site-packages\trading_calendars\trading_calendar.py in _group_times(all_days, times, tz, offset)
     68 
     69 def _group_times(all_days, times, tz, offset):
---> 70     elements = [
     71         days_at_time(
     72             selection(all_days, start, end),

~\.conda\envs\proj_ortz\lib\site-packages\trading_calendars\trading_calendar.py in <listcomp>(.0)
     69 def _group_times(all_days, times, tz, offset):
     70     elements = [
---> 71         days_at_time(
     72             selection(all_days, start, end),
     73             time,

~\.conda\envs\proj_ortz\lib\site-packages\trading_calendars\utils\pandas_utils.py in days_at_time(days, t, tz, day_offset)
     46         seconds=t.second,
     47     )
---> 48     return (days + delta).tz_localize(tz).tz_convert(UTC)
     49 
     50 

~\.conda\envs\proj_ortz\lib\site-packages\pandas\core\accessor.py in f(self, *args, **kwargs)
     97         def _create_delegator_method(name):
     98             def f(self, *args, **kwargs):
---> 99                 return self._delegate_method(name, *args, **kwargs)
    100 
    101             f.__name__ = name

~\.conda\envs\proj_ortz\lib\site-packages\pandas\core\indexes\datetimelike.py in _delegate_method(self, name, *args, **kwargs)
    903 
    904     def _delegate_method(self, name, *args, **kwargs):
--> 905         result = operator.methodcaller(name, *args, **kwargs)(self._data)
    906         if name not in self._raw_methods:
    907             result = Index(result, name=self.name)

~\.conda\envs\proj_ortz\lib\site-packages\pandas\core\arrays\datetimes.py in tz_localize(self, tz, ambiguous, nonexistent)
    983             # Convert to UTC
    984 
--> 985             new_dates = conversion.tz_localize_to_utc(
    986                 self.asi8, tz, ambiguous=ambiguous, nonexistent=nonexistent
    987             )

pandas\_libs\tslibs\tzconversion.pyx in pandas._libs.tslibs.tzconversion.tz_localize_to_utc()

AmbiguousTimeError: Cannot infer dst time from 1990-10-28 01:01:00, try using the 'ambiguous' argument

@gerrymanoim I don't see the XKTS (JPX) calendar in your difference report, but doing a spot check the holiday 2021-09-23, the Autumnal Equinox (as shown here: https://www.tradinghours.com/exchanges/jpx/market-holidays/2021) is a holiday in pandas_market_calendars but not in trading_calendars

These holidays were provided to pandas_market_calendars in this PR: rsheftel/pandas_market_calendars#72

I've found a few issues/improvements to the setup.py and PyPI:

• Libraries.io doesn't list the package's dependencies, which means that PyPI doesn't fetch or process the list of dependencies either.
• Unit tests and test framework are not referenced in the setup.py, using test_suite. [1]
• Possibly adding the test/resources as package_data or similar, to signal that is a data folder.

The section in https://github.com/quantopian/trading_calendars#usage only shows part of the functionality. Between that and https://www.zipline.io/appendix.html#trading-calendar-api we don't actually have an example of usage anywhere.

Hi,

I've been experimenting with sessions_window and I found that when the count parameter is negative and greater than the total number of days in the trading calendar, the result cycles back and returns the dates between the end date and till the exact overflow value.

Example:

from trading_calendars import get_calendar
market_calendar = get_calendar('XNYS')
end_date = '2019-02-27'
days_rqd = -8500
dates = market_calendar.sessions_window(end_date, days_rqd)
print(dates)

>>DatetimeIndex(['2016-07-12 00:00:00+00:00', '2016-07-13 00:00:00+00:00',
               '2016-07-14 00:00:00+00:00', '2016-07-15 00:00:00+00:00',
               '2016-07-18 00:00:00+00:00', '2016-07-19 00:00:00+00:00',
               '2016-07-20 00:00:00+00:00', '2016-07-21 00:00:00+00:00',
               '2016-07-22 00:00:00+00:00', '2016-07-25 00:00:00+00:00',
               ...
               '2019-02-13 00:00:00+00:00', '2019-02-14 00:00:00+00:00',
               '2019-02-15 00:00:00+00:00', '2019-02-19 00:00:00+00:00',
               '2019-02-20 00:00:00+00:00', '2019-02-21 00:00:00+00:00',
               '2019-02-22 00:00:00+00:00', '2019-02-25 00:00:00+00:00',
               '2019-02-26 00:00:00+00:00', '2019-02-27 00:00:00+00:00'],
              dtype='datetime64[ns, UTC]', length=662, freq='C')

print(len(dates))
>> 662

Upon checking the code for this in trading_calendar.py, start_idx is 7345 for the calendar I've chosen in the above example and end_idx becomes 7345 + (-8500) = -1155 and thus the output will be all_sessions[-1155: 7345 + 1] which is not what I expected. The total length of all_sessions is 7839 - so, converting the negative indices to normal indices, we get all_sessions[7839-1155: 7345 + 1] which is all_sessions[6684: 7345 + 1] which explains why I got 662 dates.

What I expect is all_sessions[0: 7345 + 1] which can be obtained by adding end_idx = max(0, end_idx) right before the indexing on all_sessions (created a pull request for the same - #125). I'm not yet sure if this affects any other functionality, but tl;dr version is, when we query dates where the lookback/negative count is greater than the length of historical dates, it should just return all the available dates till the end date instead of looping back on the indices.

When I tried to get the US calendar and call all_sessions.

The date returned is one year larger.

This applies to version 2020.1 and possibly earlier versions.

The returned early close time of 14:05 for XLIS, e.g. on 2020-12-24, is incorrect or at least ambiguous. It is incorrect if the time is meant to be in the exchange's time zone -- which is WET -- since the time is correct only in CET; cf. https://www.euronext.com/en/trade/trading-hours-holidays which lists the early close time as 14:05 CET for several Euronext exchanges that are located in both CET and WET (Lisbon) time zones. It is ambiguous if the user is expected to interpret the time in CET since there's no link to that time zone from the XLIS calendar.

In https://github.com/quantopian/trading_calendars/runs/415631169?check_suite_focus=true under 3.8, windows is not finding tests.

next_non_holiday_weekday in trading_calendar.xtks_holidays is computationally expensive as observed in #155

Hello,
I ran python etc/lunisolar lunar-ecliptic-longitude --verbose --start '2005-01-01' with python 3.5.2 and 2.7 in virtual envs. Its throwing and syntax error. It is running fine with 3.6.6 though.

  File "etc/lunisolar", line 186
    return np.datetime64(f'{year}-{month:02d}-{day:02d}', 'D')

My default python is 3.6.6, but I had to install Python 3.5 because I could not get Zipline running on 3.6. Script etc/lunisolar and Zipline are in incompatible environments.

Thanks

re rsheftel/pandas_market_calendars#41

import pandas as pd
import trading_calendars as tc
import pandas_market_calendars as pmc

def method_comparison(tc_methods, pmc_methods):
  # must be an easier way to do this
  tc_col = tc_methods.copy()
  pmc_methods_set = set(pmc_methods)

  pmc_col, pmc_only = [], []

  for method in tc_col:
    if method in pmc_methods_set:
      pmc_col.append(method)
    else:
      pmc_col.append(None)
  
  pmc_only = list(pmc_methods_set - set(pmc_col))
  pmc_col.extend(pmc_only)
  tc_col.extend([None for _ in pmc_only])
  return pd.DataFrame(
    {'trading_calendars': tc_col, 'pandas_market_calendars': pmc_col}
  )

Calendar level differences

nyse_tc = tc.get_calendar("NYSE")
nyse_pmc = pmc.get_calendar("NYSE")
calendar_method_comparison = method_comparison(dir(nyse_tc), dir(nyse_pmc))

Module level differences

def clean_methods(l):
  return [m for m in l if "exchange_" not in m]

tc_methods = clean_methods(dir(tc))
pmc_methods = clean_methods(dir(pmc))
module_method_comparison = method_comparison(tc_methods, pmc_methods)

re rsheftel/pandas_market_calendars#41

Summary status

• XHKG
  • #152 (comment)
• CFE
  • #152 (comment)
  • Note: We don't know what to do about 1994-04-27 in pmc but not in tc
• XSWX
• LSE
  • Issue: #163
  • PR: #166
• XSHG
• XASX
• TSX
  • #152 (comment))
• BMF

Extras not covered by diff below:

• Pre 1990 NYSE holidays
  • #162

Details

code generating the table below

from collections import namedtuple 

import pandas_market_calendars as pmc
import trading_calendars as tc

# todo port this back to trading calendars
def get_tc_calendar_names():
  return list(tc.calendar_utils._default_calendar_factories.keys())+list(tc.calendar_utils._default_calendar_aliases.keys())

tc.get_calendar_names = get_tc_calendar_names
# end todo

pmc_calendars = set(pmc.get_calendar_names())
tc_calendars = set(tc.get_calendar_names())
tc_to_pmc_mapping = {
    'XASX': 'ASX',
    'XHKG': 'HKEX',
    'XTKS': 'JPX',
    'XOSL': 'OSE',
    'XSWX': 'SIX',
    'XSHG': 'SSE',
}

in_both = (tc_calendars & pmc_calendars) | set(tc_to_pmc_mapping.keys())

CompareResult = namedtuple("Result", ["only_tc", "only_pmc"])

def compare_calendars(cal: str):
  tc_cal = tc.get_calendar(cal).all_sessions
  pmc_cal_name = tc_to_pmc_mapping.get(cal, cal)
  pmc_cal = pmc.get_calendar(pmc_cal_name).valid_days(min(tc_cal), max(tc_cal))
  if not (tc_cal ^ pmc_cal).empty:
    return CompareResult

out = {}
for cal in in_both:
  diff = compare_calendars(cal)
  if diff:
    out[cal] = diff

# everything below this is markdown formatting
out_str = []
for cal, result in out.items():
  out_str.append(f"## {cal} \n")
  out_str.append("Trading Days only in `trading_calendars` \n")
  out_str.extend([f"- {item} \n" for item in result.only_tc])
  out_str.append("\n")
  out_str.append("Trading Days only in `pandas_market_calendars` \n")
  out_str.extend([f"- {item} \n" for item in result.only_pmc])
  out_str.append("\n")
md = "".join(out_str); print(md)

XHKG

Trading Days only in trading_calendars

• 1990-06-18 00:00:00+00:00
• 1990-08-27 00:00:00+00:00
• 1991-02-14 00:00:00+00:00
• 1991-06-18 00:00:00+00:00
• 1991-08-26 00:00:00+00:00
• 1992-06-15 00:00:00+00:00
• 1992-07-22 00:00:00+00:00
• 1992-08-31 00:00:00+00:00
• 1993-06-14 00:00:00+00:00
• 1993-08-30 00:00:00+00:00
• 1993-09-17 00:00:00+00:00
• 1994-06-14 00:00:00+00:00
• 1994-08-29 00:00:00+00:00
• 1995-06-19 00:00:00+00:00
• 1995-08-28 00:00:00+00:00
• 1996-06-17 00:00:00+00:00
• 1996-08-26 00:00:00+00:00
• 1997-02-06 00:00:00+00:00
• 1997-06-30 00:00:00+00:00
• 1997-07-02 00:00:00+00:00
• 1997-08-18 00:00:00+00:00
• 1997-10-02 00:00:00+00:00
• 1998-08-17 00:00:00+00:00
• 1998-10-02 00:00:00+00:00
• 1999-09-16 00:00:00+00:00
• 1999-12-31 00:00:00+00:00
• 2001-07-06 00:00:00+00:00
• 2001-07-25 00:00:00+00:00

Trading Days only in pandas_market_calendars

• 1990-05-01 00:00:00+00:00
• 1990-05-02 00:00:00+00:00
• 1990-07-02 00:00:00+00:00
• 1990-10-01 00:00:00+00:00
• 1991-05-01 00:00:00+00:00
• 1991-05-21 00:00:00+00:00
• 1991-07-01 00:00:00+00:00
• 1991-10-01 00:00:00+00:00
• 1992-05-01 00:00:00+00:00
• 1992-05-11 00:00:00+00:00
• 1992-07-01 00:00:00+00:00
• 1992-10-01 00:00:00+00:00
• 1993-05-28 00:00:00+00:00
• 1993-07-01 00:00:00+00:00
• 1994-05-02 00:00:00+00:00
• 1994-05-18 00:00:00+00:00
• 1994-07-01 00:00:00+00:00
• 1995-05-01 00:00:00+00:00
• 1995-05-08 00:00:00+00:00
• 1995-10-02 00:00:00+00:00
• 1996-05-01 00:00:00+00:00
• 1996-05-24 00:00:00+00:00
• 1996-07-01 00:00:00+00:00
• 1996-10-01 00:00:00+00:00
• 1997-05-01 00:00:00+00:00
• 1997-05-14 00:00:00+00:00
• 1998-05-01 00:00:00+00:00
• 1998-05-04 00:00:00+00:00
• 2021-04-06 00:00:00+00:00

CFE

Trading Days only in trading_calendars

Trading Days only in pandas_market_calendars

• 1994-04-27 00:00:00+00:00
• 2004-06-11 00:00:00+00:00
• 2007-01-02 00:00:00+00:00
• 2012-10-29 00:00:00+00:00
• 2012-10-30 00:00:00+00:00
• 2018-12-05 00:00:00+00:00

XSWX

Trading Days only in trading_calendars

• 1994-12-30 00:00:00+00:00
• 1995-12-29 00:00:00+00:00
• 2000-12-29 00:00:00+00:00
• 2005-12-30 00:00:00+00:00
• 2006-12-29 00:00:00+00:00
• 2011-12-30 00:00:00+00:00
• 2016-12-30 00:00:00+00:00
• 2017-12-29 00:00:00+00:00

Trading Days only in pandas_market_calendars

LSE

Trading Days only in trading_calendars

• 1995-05-08 00:00:00+00:00
• 1999-12-31 00:00:00+00:00

Trading Days only in pandas_market_calendars

• 1995-05-01 00:00:00+00:00

XSHG

Trading Days only in trading_calendars

• 2020-01-31 00:00:00+00:00
• 2022-01-31 00:00:00+00:00
• 2022-04-04 00:00:00+00:00
• 2022-05-02 00:00:00+00:00
• 2022-09-12 00:00:00+00:00
• 2022-10-06 00:00:00+00:00
• 2022-10-07 00:00:00+00:00
• 2023-06-23 00:00:00+00:00
• 2023-10-06 00:00:00+00:00
• 2024-02-09 00:00:00+00:00
• 2024-04-05 00:00:00+00:00
• 2024-09-16 00:00:00+00:00
• 2024-10-07 00:00:00+00:00
• 2025-01-28 00:00:00+00:00
• 2025-05-02 00:00:00+00:00
• 2025-06-02 00:00:00+00:00
• 2025-10-06 00:00:00+00:00
• 2025-10-07 00:00:00+00:00

Trading Days only in pandas_market_calendars

• 2020-10-08 00:00:00+00:00

XASX

Trading Days only in trading_calendars

• 1993-01-27 00:00:00+00:00
• 1994-01-27 00:00:00+00:00
• 1995-01-27 00:00:00+00:00
• 1996-01-29 00:00:00+00:00
• 1998-01-27 00:00:00+00:00
• 1999-01-27 00:00:00+00:00
• 2000-01-27 00:00:00+00:00
• 2001-01-29 00:00:00+00:00
• 2004-01-27 00:00:00+00:00
• 2005-01-27 00:00:00+00:00
• 2006-01-27 00:00:00+00:00
• 2007-01-29 00:00:00+00:00
• 2009-01-27 00:00:00+00:00
• 2010-01-27 00:00:00+00:00
• 2011-01-27 00:00:00+00:00
• 2012-01-27 00:00:00+00:00
• 2015-01-27 00:00:00+00:00
• 2016-01-27 00:00:00+00:00
• 2017-01-27 00:00:00+00:00
• 2018-01-29 00:00:00+00:00
• 2021-01-27 00:00:00+00:00

Trading Days only in pandas_market_calendars

• 1990-12-31 00:00:00+00:00
• 1994-01-26 00:00:00+00:00
• 1994-12-27 00:00:00+00:00
• 1995-01-26 00:00:00+00:00
• 1996-01-26 00:00:00+00:00
• 1998-01-26 00:00:00+00:00
• 1999-01-26 00:00:00+00:00
• 1999-12-31 00:00:00+00:00
• 2000-01-26 00:00:00+00:00
• 2001-01-26 00:00:00+00:00
• 2004-01-26 00:00:00+00:00
• 2005-01-26 00:00:00+00:00
• 2005-12-27 00:00:00+00:00
• 2006-01-26 00:00:00+00:00
• 2007-01-26 00:00:00+00:00
• 2009-01-26 00:00:00+00:00
• 2010-01-26 00:00:00+00:00
• 2010-04-26 00:00:00+00:00
• 2011-01-26 00:00:00+00:00
• 2011-04-26 00:00:00+00:00
• 2011-12-27 00:00:00+00:00
• 2012-01-26 00:00:00+00:00
• 2015-01-26 00:00:00+00:00
• 2016-01-26 00:00:00+00:00
• 2016-12-27 00:00:00+00:00
• 2017-01-26 00:00:00+00:00
• 2018-01-26 00:00:00+00:00
• 2021-01-26 00:00:00+00:00

TSX

Trading Days only in trading_calendars

• 1993-12-24 00:00:00+00:00
• 1999-12-24 00:00:00+00:00
• 2004-12-24 00:00:00+00:00
• 2010-12-24 00:00:00+00:00

Trading Days only in pandas_market_calendars

• 2001-09-11 00:00:00+00:00
• 2001-09-12 00:00:00+00:00

BMF

Trading Days only in trading_calendars

• 1997-07-09 00:00:00+00:00
• 2020-07-09 00:00:00+00:00

Trading Days only in pandas_market_calendars

• 1995-12-29 00:00:00+00:00
• 2000-12-29 00:00:00+00:00
• 2006-12-29 00:00:00+00:00
• 2014-06-12 00:00:00+00:00
• 2017-12-29 00:00:00+00:00

In the README.md, there's a footnote:

Calendars marked with an asterisk (*) have not yet been released.

But no line was marked, probably meaning that all calendars are already released, right?

Should we add more calendars or remove the footnote?

Hi there,
It seems the XFRA closing time is incorrect, it is 20:00 CET.
https://www.tradinghours.com/exchanges/fsx

(Following up from rsheftel/pandas_market_calendars#41)

Hello Team,

I am new to python and wanted to know how to use the trading XBOM calendar, for example

today = datetime.date.today() i.e. 25th Dec 2019. how to check this date is in holiday list or not with condition

And also given time in market hours are not can someone help with sample code

Starting tomorrow, BVMF will extend its trading hours by one hour. [1][2]

The LSE (XLON) exchange has special holidays as described by @matthew-tomlinson in rsheftel/pandas_market_calendars#84. These are implemented in pandas_market_calendars and need to be brought to trading_calendars. In pcal they are implemented in the https://github.com/rsheftel/pandas_market_calendars/blob/master/pandas_market_calendars/holidays_uk.py module here. There are tests in the test_exchange_calendar_lse.py that can be used to confirm.

# Early May bank holiday has two exceptions based on the 50th and 75th anniversary of VE-Day
# 1995-05-01 Early May bank holiday removed for VE-day 50th anniversary
# 2020-05-04 Early May bank holiday removed for VE-day 75th anniversary

# Early May bank holiday pre-1995
MayBank_pre_1995 = Holiday(
    "Early May Bank Holiday",
    month=5,
    offset=DateOffset(weekday=MO(1)),
    day=1,
    end_date=Timestamp('1994-12-31'),
)

# Early May bank holiday post-1995 and pre-2020
MayBank_post_1995_pre_2020 = Holiday(
    "Early May Bank Holiday",
    month=5,
    offset=DateOffset(weekday=MO(1)),
    day=1,
    start_date=Timestamp('1996-01-01'),
    end_date=Timestamp('2019-12-31'),
)

# Early May bank holiday post 2020
MayBank_post_2020 = Holiday(
    "Early May Bank Holiday",
    month=5,
    offset=DateOffset(weekday=MO(1)),
    day=1,
    start_date=Timestamp('2021-01-01')
)

# Spring bank holiday has two exceptions based on the Golden & Diamond Jubilee
# 2002-05-27 Spring bank holiday removed for Golden Jubilee
# 2012-05-28 Spring bank holiday removed for Diamond Jubilee

# Spring bank holiday
SpringBank_pre_2002 = Holiday(
    "Spring Bank Holiday",
    month=5,
    day=31,
    offset=DateOffset(weekday=MO(-1)),
    end_date=Timestamp('2001-12-31'),
)

SpringBank_post_2002_pre_2012 = Holiday(
    "Spring Bank Holiday",
    month=5,
    day=31,
    offset=DateOffset(weekday=MO(-1)),
    start_date=Timestamp('2003-01-01'),
    end_date=Timestamp('2011-12-31'),
)

SpringBank_post_2012 = Holiday(
    "Spring Bank Holiday",
    month=5,
    day=31,
    offset=DateOffset(weekday=MO(-1)),
    start_date=Timestamp('2013-01-01'),
)

Here's the list of holidays for NSE. Problem is, there are some holidays which follow Gregorian calendar (eg. Republic day, Independence day, Mahatama Gandhi Jayanti etc), some holidays which follow Hindu Calendars (eg. Diwali, Holi) and few holidays follow Islamic calendar (Ramzan, Eid)

How to deal with this. One option I could think is work backwards from data. Take the data of a stock which has traded longest and then figure out holidays based on it.

I am looking at hk branch but have not been able to figure out any solution yet.

Any help on this will be appreciated.

Thanks

I didn't get a chance to dig into why this is happening, but thought I'd mention it. Hopefully this isn't predicting the end of the world! pd.date_range() responds as expected for these inputs, so I think it's a local issue not upstream, but didn't dig too far.

I have hope there is plenty of time for us to fix the future!

from trading_calendars import get_calendar

# US Stock Exchanges (includes NASDAQ)
XNYS_calendar = get_calendar('XNYS')

print("Last month is 2019-10:")
print( XNYS_calendar.sessions_in_range("2019-10", "2020") )

print("2019-11 and beyond:")
print( XNYS_calendar.sessions_in_range("2019-11", "2020") )

Results:

Last month is 2019-10:
DatetimeIndex(['2019-10-01', '2019-10-02', '2019-10-03', '2019-10-04',
               '2019-10-07', '2019-10-08', '2019-10-09', '2019-10-10',
               '2019-10-11', '2019-10-14', '2019-10-15', '2019-10-16',
               '2019-10-17', '2019-10-18', '2019-10-21', '2019-10-22',
               '2019-10-23', '2019-10-24', '2019-10-25', '2019-10-28',
               '2019-10-29', '2019-10-30'],
              dtype='datetime64[ns, UTC]', freq='C')

2019-11 and beyond:
DatetimeIndex([], dtype='datetime64[ns, UTC]', freq='C')

Following up from rsheftel/pandas_market_calendars#41

(Resurfacing #54)

In .travis.yml, coveralls is installed and runs in the end of the pipeline:

but apparently the project is not created in the Coveralls website [1], basically discarding any report sent. Am I right?