We build market calendars. The Indian one has been on PyPI for a while. The Lithuanian one is new, and it is built on a different principle: holidays are computed, not tabulated.
pip install aion-lithuanian-market-calendar
The problem with hardcoded holiday tables
Most holiday libraries ship a dictionary of dates. Someone types them in for the next few years, and the package works until it silently does not.
Two things go wrong.
The table runs out. Ask for 2031 and you get a wrong answer or an exception, usually the former, usually discovered in production.
And moveable feasts are typed by hand. Easter moves every year on a rule that is not obvious, and every holiday anchored to it moves with it. A hand-typed table is a hand-typed opportunity to be wrong in a year nobody has checked yet.
Computing instead
Lithuania observes 16 public holidays. Most are fixed dates. The moveable ones derive from Easter, which is computed with the Anonymous Gregorian algorithm — sometimes called Meeus/Jones/Butcher.
Lithuania is predominantly Roman Catholic and uses the Western (Gregorian) computus, not the Orthodox one. The two diverge by weeks in most years. Getting this wrong is the kind of error that looks fine in the year you test it and fails later.
Because the rule is computed, any year works:
from aion_lithuanian_market_calendar import holidays
for h in holidays(2031):
print(h.date, h.name_en, "|", h.name_lt)
No table to exhaust. No year that quietly falls off the end.
Bilingual by default
Every holiday carries both an English and a Lithuanian name:
| English | Lithuanian |
|---|---|
| Independence Restoration Day | Lietuvos nepriklausomybės atkūrimo diena |
| St John's Day | Rasos ir Joninės |
| Statehood Day | Valstybės diena |
A Lithuanian user should not have to read their own national holidays in English. That is not localisation as a feature, it is the minimum.
Offline
The package makes no network calls in normal use. No telemetry on bundled lookups, no phone-home, no API key. It computes locally and returns.
That matters for anything running in CI, in an air-gapped environment, or at scale where an outbound request per date check is absurd.
What we are still unsure about
Three questions are open, and we would rather say so than imply a completeness we have not verified:
- Completeness. We believe the 16 are correct. We have not had them reviewed by someone who has lived a Lithuanian working year.
- Father's Day. The rule we implement gives the first Sunday of June. We are confident about the rule and less confident that our source was authoritative.
- Weekend substitution. When a public holiday falls on a Saturday or Sunday, does Lithuania grant a substitute weekday? Some countries do, some do not, and this materially changes business-day arithmetic. We currently do not substitute.
If you are Lithuanian and any of these are obviously wrong to you, that is exactly the kind of correction we want. The repository is open.
Why a market calendar company built this
Trading systems ask one question constantly: is the market open right now, and if not, when does it next open? Getting it wrong means orders into a closed session, settlement maths off by a day, and backtests that quietly include days that never traded.
We built aion-indian-market-calendar for NSE, BSE and MCX first because that is our home market. The Lithuanian calendar applies the same principle to a different jurisdiction: compute the rule, do not type the dates.
- Package: pypi.org/project/aion-lithuanian-market-calendar
- Source: github.com/AION-Analytics-India/aion-lithuanian-market-calendar
- Project page: dashboard.aiondashboard.site/open-source/lithuanian-market-calendar
Corrections welcome, particularly from Lithuanian readers.
Top comments (0)