Upgrading 5.0 → 5.1

5.1 breaks three types, corrects two dasha tables, moves two festival timings, and adds one opt-in flag. The type breaks ship in a minor release on purpose, because v5 was days old. Pin 5.0.x until you have applied them. All three broke fields that did not match the reference almanac.

Three fields became arrays

Each of these published a single window, or a fixed pair, on days that can carry a different number of them. The migration is mechanical.

- if (r.inauspicious.varjyam) show(r.inauspicious.varjyam);   // TimePeriod | null
+ r.inauspicious.varjyam.forEach(show);                       // TimePeriod[], [] when none

- const [dm1, dm2] = r.inauspicious.durMuhurta;               // fixed 2-tuple
+ r.inauspicious.durMuhurta.forEach(show);                    // DurMuhurtaPeriod[], 1-2 windows

- if (r.muhurtas.amritKala) show(r.muhurtas.amritKala);       // TimePeriod | null
+ r.muhurtas.amritKala.forEach(show);                         // TimePeriod[], 0-2 windows

• inauspicious.varjyam is now TimePeriod[]. 5.0 looked only at the sunrise nakshatra and dropped the second window that printed panchangs show on transition days. 5.1 publishes every window whose start falls in the Hindu day, in start order and unclamped, which is how the reference almanac attributes them. Mula's second tyajya spell (elapsed ghatikas 20 and 56) is emitted now too. There is a new export, computeVarjyamWindows. The single-window computeVarjyam primitive keeps its signature and returns the earliest overlapping spell.
• inauspicious.durMuhurta is now DurMuhurtaPeriod[]. The old table emitted two day windows every day, and matched the reference almanac on none of the seven weekdays. The corrected Muhurta-Chintamani table gives one window on Sunday and Wednesday and two on the other days. Tuesday's second window falls at night, at the 7th of the fifteen sunset-to-sunrise muhurtas, so a fixed pair of day windows could not survive. Each entry carries segment, either 'day' or 'night'. Checked against 58 consecutive reference-almanac day-pages across two cities.
• muhurtas.amritKala is now TimePeriod[]. Amrit Kala works the way Varjyam does, and the reference almanac prints the two from the same frame. Each window anchors at its own nakshatra's start, offset by a per-nakshatra count of nakshatra-elastic ghatikas, spans exactly four such ghatikas, and belongs to the Hindu day its start falls in. That gives 0 to 2 windows a day. The old sunrise-anchored single window disagreed with the reference almanac by up to ~16 h. computeAmritKala is replaced by computeAmritKalaWindows(sunriseUtc, nextSunriseUtc, getMoon).

Two dasha starting lords corrected

Both were wrong for every birth. Discard anything you recorded from 5.0 or earlier rather than trying to reconcile it.

• Yogini starting lord. It was nakshatraIndex % 8, which is off by three for every birth. It now uses the classical Devi-Bhagavata formula, ((1-based nakshatra + 3) mod 8): Ashwini → Bhramari, Pushya → Dhanya.
• Ashtottari starting lord. It was a years-proportional split from a Krittika anchor, which matches no source. It now uses the classical Ardradi group table, whose eight groups run from Ardra and hold four nakshatras for the Sun, Mars and Rahu and three for the other five lords, and takes the balance from the elapsed fraction of the group. The group table itself is not exported. The package ships ASHTOTTARI_ORDER and ASHTOTTARI_YEARS.

Full tables and the group model are in Dashas & Transits.

Ekadashi splits and regional new years move

Neither of these changes a type, so the compiler will not flag them. The dates move on affected days.

• Ekadashi splits: Smarta first, Vaishnava second. On the days the reference almanac prints an Ekadashi twice, the earlier day is the Smarta fast and the later one the Vaishnava fast. If you keyed off smarta_ekadashi / vaishnava_ekadashi on split days, the two now swap places. computeEkadashiDatesForYear is unchanged. Custom locale packs need the renamed viddha description keys.
• Regional solar new years land on their own days. vishu, baisakhi and pohela_boishakh no longer share Puthandu's day. Each keys off the Mesha transit moment in its own way. In 2027 Vishu and Pohela Boishakh fall on April 15 while Puthandu falls on April 14. In 2028 Baisakhi falls on April 13 while the rest fall on April 14. getHinduNewYear follows the same per-region rules.

// Ekadashi keys only. Other festivals on these days are unchanged.

  // Dashami-viddha day (e.g. 2027-10-25)
- ['vaishnava_ekadashi', 'smarta_ekadashi' /* deferred */, 'ekadashi']
+ ['smarta_ekadashi', 'ekadashi']          // vaishnava_ekadashi is tomorrow

  // First day of a vriddha Dwadashi (e.g. 2026-08-24)
- []
+ ['vaishnava_ekadashi']

Opt-in Gana-dosha cancellation

Pass computeAshtakoot(boy, girl, { ganaCancellation: true }) to turn it on. Leave it out and the output is byte-identical to 5.0. See Matching & Doshas.

Corrections without shape changes

These ride along in 5.1 without moving a type. Times and verdicts move on affected days, so re-run anything you cached.

• Corrected dur muhurta ordinals and night choghadiya names. Bhadra vasa is now keyed on the Moon rashi, with a piecewise vasa segment list on BhadraInfo.
• Night-transit Sankranti dates, plus a new moment field on SankrantiEvent. Also the kshaya-Dwadashi Ekadashi advance and the Kali Yuga year boundary.
• Vijayadashami, Karva Chauth and Janmashtami kala rules, scoreMuhurta special-yoga parity, eastern-longitude Gulika/Mandi, and the opt-in Ashtakavarga reductions.