How juno.date Corrects Historical Indian Time

War Time, Calcutta Time, the arithmetic in full — and the same certificates put to the biggest sites in the business, with credit given wherever it is due.

1. Why this matters — in one table

The full stories live in our companion articles on the War-Time births and diaspora DST errors; here is the consequence summary that motivates everything below. When a tool misreads the civil clock by a fixed interval, the planets barely move — but the time-anchored skeleton of the chart breaks:

Table 1 — What an uncorrected historical offset does to a birth chart (rates derived from lunar/ascendant motion; see the companion sensitivity analysis).

These are not exotic cases. The affected cohorts — births of 1935–48 Bengal and all-India 1941–45 — are today's family elders, whose charts anchor matching discussions, milestone ceremonies and family memory. If a chart is worth computing at all, it is worth computing against the clock that actually ticked in the room.

2. What we apply, exactly

Layer 1 — the IANA civil-time database (War Time and everything standard)

Every birth entered on juno.date is resolved from certificate clock to Universal Time through the IANA tz database — the historically researched record of the world's civil-time rules that operating systems themselves use. For India this carries the two War-Time spells: clocks advanced to UTC+6:30 from 1 October 1941 to 15 May 1942 and again from 1 September 1942 to 15 October 1945. No checkbox, no user question: if the date falls inside a spell, the conversion uses +6:30.

Claims are cheap, so we probed our own engine at all four boundaries and publish the probes. Method: same city (Delhi), same clock time, a few days on either side of each boundary — seasonal drift moves the lagna only ~1° per day, so the one-hour jump is unmistakable:

Table 2 — Boundary verification of our own engine. Every probe is a plain /jataka computation you can repeat today.

Layer 2 — the period-adjustment table (what the database intentionally omits)

The tz database models each region's standard zone. It does not model administrative survivals — and the great Indian example is Calcutta Time: UTC+5:53:20, the old Bengal standard, which remained official in the Calcutta area until 1948, twenty-three minutes and twenty seconds ahead of IST. A 1947 Kolkata certificate very likely records Calcutta Time; every mainstream engine reads it as IST.

So we built the missing layer: a dedicated period-adjustment table — region (as a centre and radius), period, true clock-to-UTC offset, a documentation-grade confidence rating, and a plain-language note. When a birth falls inside a listed region and period, the certificate clock is interpreted at the historical offset — and the chart says so. Every corrected chart carries the note verbatim, for example:

Currently seeded: the Calcutta Time windows of 1935–48 — excluding the War-Time spells, during which the +6:30 war clock governed Bengal too (the layers compose; they never double-correct). Deliberately not auto-applied: Bombay Time (UTC+4:51), which persisted only unofficially into the 1950s with famously mixed usage — forcing it on every Bombay birth would be over-correction, so it is documented for manual handling and queued as an opt-in flag. And two honesty notes we insist on making ourselves before anyone else can: the Calcutta rows carry medium confidence, because institutions running on IST existed in Calcutta too — where a family knows their record was railway-style IST, the note tells them exactly what was assumed and by how much to read past it; and historical timekeeping research is never finished — as better records surface, the table will be revised, and its seed data is versioned in our repository for exactly that reason. Reconstructing who meant what by "8 o'clock" in 1947 Bengal is genuinely hard; we claim care, not omniscience.

3. The arithmetic, step by step

Case A — War Time: 15 June 1943, 6:00 AM, Delhi

Case B — Calcutta Time: 15 June 1947, 7:20 AM, Calcutta

Both cases are live on juno.date/jataka right now — enter them and watch the corrections apply. That reproducibility is the entire point.

4. The comparison — no site escapes, including the ones we like

Our earlier reviews credited several competitors honestly: ProKerala passed our daylight-saving test where others failed; Drik Panchang passed our time-handling verification cleanly; AstroSage reproduced our positions to the arc-second apart from one DST nuance. Those results stand — and precisely because those sites are good, they make the right benchmark for a harder test. Handling US daylight saving requires using the timezone database correctly; handling 1943 Delhi or 1947 Kolkata requires it too — plus, for Calcutta Time, research the database itself does not contain. Passing the easy layer says nothing about the hard one. So we put Cases A and B (and a control that everyone should get right) to each site, same certificates, screenshots unedited:

Table 3 — The test certificates. Case C exists so that no difference can be blamed on ayanamsa or ephemeris quality: any engine that agrees on C but diverges on A or B differs specifically in historical time handling.

Read what the wrong column costs. In both historical cases the correction moves the ascendant a full sign — Rishaba becomes Mithuna, Mithuna becomes Kataka — while the slow-moving Moon keeps the same nakshatra and rasi (Swati/Thula in A, Aswini/Mesha in B). That is the signature of a time error, and it is exactly why it slips past casual checking: the birth star looks right, so nobody suspects the clock, yet the entire house framework — lagna, every bhava, the navamsa ascendant, the muhurtham fitness — is built on the wrong minute. A matching report keyed to the star survives; a full jātakam reading does not. Our birth-time sensitivity study quantifies the same effect from the other direction.

4.1 ProKerala — Case A: correct

Verdict — ProKerala passes Case A, and we credit it plainly. Given 15 June 1943, 06:00, Delhi, ProKerala resolves the birth time to +06:30 — India's War-Time offset — and computes Rishaba lagna, matching juno.date exactly, graha for graha (Mars in Meena; Sun, Mercury, Saturn and the Ascendant in Rishaba; Venus, Jupiter, Rahu in Kataka; Ketu in Makara; Moon in Thula). This is not the user supplying the offset: ProKerala's birth-chart form takes only name, date, time and place — there is no timezone or offset field to fill (you can confirm this on their form yourself). The +06:30 is therefore derived by ProKerala automatically from "Delhi, June 1943", exactly as the standard timezone database encodes War Time. So the site we already credited for daylight saving handles India's own war hour too — a clean pass on Case A. This is the fairness rule working as designed: where a tool is right, it is right in bold.

And there is a second, quieter result worth stating — one that flatters both engines. Read ProKerala's degrees against ours for the identical birth. This is our own DE440 engine, built from scratch, put beside the mature Astro-Vision engine ProKerala runs:

Table 4 — juno.date vs ProKerala on Case A, every body to the arc-minute. Mean difference 0.8′; every body agrees on sign and nakshatra.

Two independent engines — different code, different ephemeris source, different authors, twenty years apart — land within about one arc-minute on every graha of a difficult 1943 war-year birth. That is not a coincidence to gloss over; it is mutual verification. When a purpose-built engine and a long-established commercial one agree this closely, the reader can trust the number, whichever site produced it. We would rather show that than pretend a gap exists where none does.

Is there any gap at all? A tiny, honest one — and it is worth dissecting, because doing so shows exactly why it is not an accuracy defect. Our figures run uniformly ~0.8′ higher than ProKerala's, the same direction on every single body. There are only three things that shift, and we can rule two out by arithmetic:

It is not the clock. A time or ΔT difference would betray itself by speed: the Ascendant moves 360° a day, so a few seconds of clock error would swing it minutes of arc, while slow Rahu and Ketu (0.05° a day) would barely stir. The data shows the opposite — Rahu and Ketu, the two slowest bodies, carry the full ~1′ offset. To produce that from a clock difference would take 7.6 hours, and both engines used 06:00. So the offset cannot be time. It is not the ephemeris either — DE440 and a Swiss-Ephemeris-class solution agree to milli-arc-seconds, and an ephemeris error would scatter both directions, not march uniformly one way. What is left is the ayanamsa — the fixed offset each engine subtracts to reach the sidereal zodiac, applied identically to every body. A uniform shift is its exact fingerprint. (The same test settles the nodes: both engines use the mean node — a true-node difference would throw Rahu-Ketu off by degrees, not one arc-minute.)

Whose ayanamsa is canonical? Classical Lahiri — Spica fixed at 180°, anchored at 23°51′11″ for J2000 — precesses to 23°03′50″ for this birth. Each engine against that textbook value:

Table 5 — The ~0.8′ gap, resolved to its source: a fractionally different ayanamsa. juno.date matches textbook Lahiri to three arc-seconds.

ProKerala's ~0.7′-higher value is consistent with the True Chitrapaksha variant or a slightly different Lahiri constant — a legitimate convention choice, simply not the classical 23°51′11″ Lahiri its label names. That is the whole of the "gap": a chosen flavour of ayanamsa, resolved to the arc-second, with no error on either side to crow about. On the raw astronomy — where a real accuracy claim would live — both engines are essentially perfect, and we say so plainly.

4.1b ProKerala — Case B: the Calcutta-Time gap, confirmed

Verdict — Case B is the divergence, and it is exactly the one we predicted in advance. Given the same certificate, juno.date computes Mithuna lagna (27°21′) and ProKerala computes Karka (2°28′) — a full sign apart. The cause is printed on ProKerala's own page: it reads the 1947 Kolkata clock as IST (+05:30). In June 1947 the civil clock in the Calcutta area was Calcutta Time (UTC+05:53:20), which remained in local use until 1948. The gap is 23m20s — and this birth sits 2°39′ from the Mithuna/Karka boundary, so 23 minutes is enough to carry it across.

Here is the part that makes the diagnosis airtight rather than a difference of opinion. We fed ProKerala's own assumption — the same instant read as IST — into our engine, and it returns 2°28′ Karka: their figure, to the arc-minute. The two engines' astronomy is therefore identical; the entire disagreement is one layer of civil-time history, nothing else.

Table 6 — The Case B divergence isolated. Identical ephemeris, identical ayanamsa; one difference of 23m20s in what the clock meant.

Is this ProKerala's error? We said in advance that we would answer that fairly, so: this is not a coding mistake, and it is not carelessness. ProKerala is faithfully following the IANA timezone database, which moves India to IST in 1906 and carries no entry for Calcutta Time thereafter. Every tool built on that database — which is nearly all of them — will read this certificate the same way. The limitation is inherited from the data source, and it is the precise gap our period-adjustment layer exists to fill. What we do claim, plainly: for pre-1948 births in the Calcutta region, juno.date is right and the database-default answer is wrong — and because we know the correction is a judgement about historical civil practice rather than a certainty about one family's clock, we print it on the chart in words rather than applying it silently. That note is the difference between a correction and an assumption.

4.2 Drik Panchang

Verdict — pending screenshots. Drik Panchang's time handling passed our earlier verification without qualification, and its engineering culture is the most transparent among the majors — if any mainstream site resolves Case A correctly, we expect it to be this one, and we will be glad to print it.

4.3 AstroSage

Verdict — pending screenshots. AstroSage's ephemeris matched ours to the arc-second; its one weakness in our testing was precisely time-resolution (the US DST nuance). Case A asks the same class of question about India's own history.

4.4 Meanwhile — the tools already on record getting time wrong

The three sites above are the field's best, tested on history's hardest layer; their verdicts await screenshots. But the review series has already caught popular tools mishandling the easy time layers, with evidence in hand — so the "results vs tools that are wrong" comparison is not hypothetical:

Table 7 — Popular tools already measured on time handling, from the review series. If a site misses US daylight saving — a single database lookup — the odds it models 1947 Kolkata, which no standard database carries, are slim. That is the reasoning Cases A and B put to the test above.

5. Reproduce everything yourself

No screenshot of ours needs trusting either. To verify Case A: compute 15 June 1943, 06:00, Delhi on /jataka, then compute 15 June 1946, 06:00, Delhi. The Sun stands within a quarter-degree of the same longitude in both — but the lagna differs by a sign (Rishaba vs Mithuna). Only the clock's meaning changed between those years; that difference is War Time, applied. To verify Case B: compute 15 June 1947, 07:20, Calcutta and read the correction note on the chart; then move the same birth to 1949 and watch the note disappear and the lagna shift. To verify our boundary table (Table 2), run the same probes we did — any of them is three minutes' work. An engine that shows its longitudes to the arc-second is asking to be checked; consider this the invitation.

6. What we promise going forward

Three commitments, so this article stays honest as it ages. First, the period-adjustment table is a living research artifact: its seed data and sources are versioned, and documented additions (princely-state practices, Burma-border zones, further municipal survivals) will be applied and changelogged as records are verified — with the same automatic-but-announced policy. Second, every correction we apply will always be visible on the chart it touched: silent fixes are how this field lost trust in the first place. Third, if readers hold period documents — old certificates, hospital registers, panchang margins with clock notes from 1935–48 Bengal especially — we actively want to see them; primary evidence outranks every secondary source in this table, and contributors will be credited in the article's revision notes. We are proud of this work precisely because it can absorb correction.

7. Quick answers

Does any of this affect modern births?

No — for births after 15 October 1945 outside the Calcutta window (and after August 1948 everywhere), IST applies and every engine agrees. This work is for the elders' charts — which is to say, for the charts families argue about most.

What if my 1947 Kolkata record was actually kept in IST?

The note tells you exactly what was assumed (+23m20s); the star-anchored comparison protocol in the War-Time article settles individual cases. An assumption you can see is an assumption you can overrule — that is why the note exists.

Why not just let users pick the offset?

Because the person typing is rarely the person who was born, and nobody remembers a 1942 gazette notification. Defaults must be researched; overrides must be informed. We supply the research and the information; the family supplies the memory.

Will you add more regions?

That is the table's purpose. Documented candidates are listed in our repository notes; each ships only when we can state period, region and offset with sources — the same bar this article's cases met.