pandas_market_calendars ships the exchange holidays pandas leaves out

The gap pandas leaves on purpose

The overview explains the design decision behind the package, and it is a decision rather than an oversight. The pandas package is widely used in finance and specifically for time series analysis, and it includes excellent functionality for generating sequences of dates and capabilities for custom holiday calendars, but as an explicit design choice it does not include the actual holiday calendars for specific exchanges or OTC markets. That choice makes sense for a general purpose data library, since the maintainers of pandas cannot be the authority on when the London Stock Exchange closes, and it leaves a hole that every trading application has to fill. pandas_market_calendars looks to fill that role with the holiday, late open and early close calendars for specific exchanges and OTC conventions, and it provides access to over 50 unique exchange calendars for global equity and futures markets.

The lineage is Zipline, then the exchange_calendars mirror

The history is worth knowing, because it explains the shape of the package. This package is a fork of the Zipline package from Quantopian and extracts just the relevant parts, with all credit for their excellent work to Quantopian. From version 2.0 it also provides a mirror of all the calendars from the exchange_calendars package, which itself is the maintained fork of the original trading_calendars package, and that is where the fifty-plus calendars came from. The dependency is in the packaging metadata as exchange-calendars>=3.3 alongside pandas>=1.1. The practical consequence for a user is that a change in exchange_calendars can change the output here, and the README says so directly, that calendars mirrored from exchange_calendars likewise use the version installed in the local Python environment, not a live data feed. So the effective behaviour of the package depends on the version of a dependency you may not think about.

The calendar data is code, and that has consequences

The Calendar Data and Updates section is the one to read before you build on it. Calendars and their rules are shipped as package code, and pandas_market_calendars does not request market hours from a server at runtime. To receive corrected or updated market hours you install a newer package release or update the source code. That is a deliberate design, and it has two consequences. The good one is that the library is deterministic and works offline, in a test, and in a backtest where the same input has to give the same answer months later, and there is no network call in the middle of a research pipeline. The bad one is that a calendar correction is a release, so a wrong holiday stays wrong until you upgrade, and a team running two environments can quietly disagree about whether a market was open. The package is a snapshot of the exchange calendars at a point in time, and the documentation says so rather than pretending otherwise.

The quick start, and a date_range that knows about the close

The usage is a calendar object and a schedule. You create one by name, and you can list the available names:

import pandas_market_calendars as mcal

# Create a calendar
nyse = mcal.get_calendar('NYSE')

# Show available calendars
print(mcal.get_calendar_names())

The schedule method then gives you the open and close times for each session in a date range, which in the documentation's example is a week in July 2012 where the third session closes early at 17:00 rather than 20:00, because that day is a holiday half day:

early = nyse.schedule(start_date='2012-07-01', end_date='2012-07-10')

The part that earns the package its place is date_range, which returns a DatetimeIndex containing only the datetimes when the market is open, so a daily resample of intraday data lands on the right bars:

mcal.date_range(early, frequency='1D')

With a frequency of 1D the result is one timestamp per session, at the close, and with a frequency of 1H it is every open hour of every session, skipping the 4 July session entirely because the market was closed. The output is a DatetimeIndex with a UTC dtype and no frequency, which is the correct shape for a calendar that is not a regular series.

Five major versions, each one a feature

The Major Releases section reads like a changelog written as a design history, and it is the clearest explanation of what the package can do. As of v1.0 it only works with Python 3, consistent with pandas dropping Python 2. As of v1.4 it has the concept of a break during the trading day, which accommodates Asian markets with a lunch break and futures markets that are open 24 hours with a break for trade processing. As of v2.0 it mirrors all the exchange_calendars calendars, adding over fifty. As of v3.0 the date_range function is more complete and consistent, with the discussion in PR 142 and issue 138. As of v4.0 the package provides the framework to add interruptions to calendars, which can be added to a schedule and viewed with the new interruptions_df property. As of v5.0 it uses the new zoneinfo standard for timezones and deprecates and removes pytz. The releases follow the same numbering, with v4.5.1 in January 2025, v4.6.1 later that month, v5.0.0 in April 2025, and the last push to the repository on 2026-10-05.

Product specific calendars, and the interruption model

Two features are worth pulling out because they are the ones a futures or an Asian market user needs. The first is the product specific calendars, since the package contains them for future exchanges which have different market open, closes, breaks and holidays based on product type, so a futures contract and the index it tracks do not share a session. The second is the interruption framework from version 4.0, which lets you add interruptions to a calendar and then look at them through the interruptions_df property on a schedule, so a lunch break is a first class thing in the data rather than a gap you discover later. Between the two, the package covers the awkward cases that a simple list of holidays cannot express, which is why it is more than a holiday list despite starting as one.

Where the package stops

The limit is that this is a calendar library and not a market data service, and the README is explicit about the boundary. It gives you when a market was open, and it gives you the holidays, the late opens, the early closes and the breaks, and it does not give you the prices, and it does not tell you about a holiday that was announced after the release you have installed. For a backtest that has to be reproducible, that is the right trade, because a live feed makes a backtest irreproducible, and for a production system that must know about an unscheduled closure today, it is the wrong trade and you need a data vendor for that. The second limit is the dependency surface, since the mirrored calendars come from exchange_calendars and a change there changes the output here, so pinning matters. The third is the drift between the documentation and the packaging, since the README says version 5.0 raised the minimum Python version to 3.9 while the pyproject requires Python 3.10 or above, and the project version there reads 5.5.0 while the newest tagged release is v5.0.0. The licence is MIT with a NOTICE file, the package is on PyPI and there is an Arch Linux package in the AUR.

Editorial conclusion

pandas_market_calendars is the right dependency if you resample or align market data in pandas, because the alternative is a home grown holiday list that is wrong once a year, and this package has fifty markets of them, with the late closes and the intraday breaks handled rather than approximated. It is the wrong tool if your data is not exchange traded, and it is the wrong tool if you need corrections applied on the day they are announced, because the calendars are shipped as code and a fix arrives in the next release. Before you depend on it, read the data section of the documentation and know that the values are a release behind reality, and check the interruption support if your market has a lunch break or a session close, since that arrived in version 4.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. rsheftel/pandas_market_calendars on GitHub