Festivals

Why Diwali 2026 Falls on 8 November

The full derivation, with the overlap minutes the engine actually used — and why a sunrise-matching engine picks the wrong day.

TathaAstu Team6 min read

Diwali 2026 falls on 8 November. Diwali 2027 falls on 29 October. Neither of those dates is obvious from a calendar, and the reason they differ by more than a week is the same reason festival dates are hard to compute: the answer depends on a lunar interval intersecting a solar window.

This article walks through the 2026 derivation completely, with the numbers the engine actually used.

The rule

Lakshmi Puja — the Diwali observance proper — is celebrated on the Amavasya (new moon) that prevails during Pradosha, the window just after sunset. The authorities are Dharmasindhu and Nirnaya Sindhu, and the operative word is *prevails*: the question is not which tithi was running at sunrise, but whether Amavasya is present during that specific evening window.

Pradosha is not a clock time. It runs from sunset to sunset plus two-fifteenths of the night length, which works out to roughly 96 minutes and shifts with latitude and season.

The astronomy

For New Delhi in November 2026, Amavasya runs from 8 November at 11:28 to 9 November at 13:01. That single interval touches two calendar days, which is what makes the date ambiguous and why a rule is needed at all.

The tithi interval
Amavasya (Kartika, amanta)
  start  2026-11-08T11:28:00+05:30
  end    2026-11-09T13:01:00+05:30

Pradosha
  2026-11-08  17:31 - 19:07
  2026-11-09  17:31 - 19:07

The evaluation

On 8 November, Amavasya began at 11:28 and is still running when Pradosha opens at sunset. It covers the entire window: 96 minutes of overlap out of 96 available. A full match.

On 9 November, Amavasya ended at 13:01 — four and a half hours before Pradosha begins. Overlap is zero.

Full overlap on exactly one day is the first branch of the tie-break hierarchy, so the engine never needs to reach the later branches. It selects 8 November with confidence 100 and the label FULL_KALA_COVERAGE.

The muhurat, and the text it rests on

The rule above settles which day. The same rule settles the hour: Lakshmi Puja is performed in that Pradosha, so for New Delhi on 8 November 2026 the recommended window is the whole of 17:31 to 19:07 — Amavasya covers all 96 minutes of it.

Lakshmi Puja Muhurat — New Delhi, 8 November 2026
window        17:31 - 19:07 IST  (96 min)
kala          PRADOSHA
reason        pradosha_amavasya
basis         Amavasya is pradosha-vyapini on this civil day

A time on its own is an assertion. Every muhurat the API returns therefore carries the rule it applied and the printed text that rule is drawn from, so a reader can check it rather than trust it:

provenance, as returned by /v1/festivals/muhurat
verification   verified
rule_id        muhurat.diwali.lakshmi_puja.pradosha_vyapini
rule           Lakṣmī-pūjā is performed in the pradoṣa when
               Amāvāsyā is pradoṣa-vyāpinī.
primary_text   Dharmasindhu (Kāśīnātha Upādhyāya)
reference      अथामावास्याभ्यङ्गनिर्णयः, p.93
muhurta_basis  Muhūrta Cintāmaṇi (Rāma Daivajña)
authority      Dharmaśāstra nirṇaya
calculation    Location-specific sunset + pradoṣa-vyāpinī Amāvāsyā
               (qualifying tithi) → pradoṣa window

In plain terms: Dharmasindhu, by Kāśīnātha Upādhyāya, in the section अथामावास्याभ्यङ्गनिर्णयः at page 93, is the text that places Lakshmi Puja in the Pradosha during which Amavasya prevails. The window is not a stored clock time. It is derived for the location asked about, from that rule, using the sunset for that date and the tithi that qualifies under it — which is why it moves between cities and between years.

verification: verified means the rule is traced to a named printed source rather than inferred. Where a festival has no such trace the API says so instead of returning a confident-looking time.

Why a naive engine gets this wrong

Consider what a sunrise-matching engine sees. At sunrise on 9 November, Amavasya is running — it does not end until 13:01. A rule that says "the day whose sunrise falls in Amavasya" therefore selects 9 November, and the app tells its users Diwali is a day late.

This is not a hypothetical failure mode. Ganesh Chaturthi, Vijayadashami and Maha Shivaratri were all one day late in our own production system before the engine was rebuilt around interval evaluation. Those corrections are documented in the changelog.

Checking it yourself

The whole derivation is available from the API, and the confidence score tells you how the decision was reached rather than making you take it on trust.

Request
curl "https://api.tathaastuapi.com/v1/festivals?date=2026-11-08&location_id=1" \
  -H "X-API-Key: $TATHAASTU_API_KEY"
Response (abridged)
{
  "festival_key": "FESTIVAL_DIWALI",
  "date": "2026-11-08",
  "confidence": 100,
  "confidence_label": "FULL_KALA_COVERAGE",
  "rule_code": "DIWALI_V2",
  "rule_version": 2,
  "priority_tier": "MAJOR",
  "primary": true
}
The same request for 2027 returns 29 October. If you are hardcoding festival dates in your application, this is the gap that will eventually produce a support ticket.
FestivalsDiwaliWorked example