juno.date · Research

Drik Panchang: Getting the Time Right

We don't only document what tools get wrong. When one gets it right, we say so — and here is one that does.

Abstract. drikpanchang.com is a widely used drik (observation-corrected) panchang and chart calculator. Across the time-critical quantities we test — the birthplace's coordinates, its local timezone, and daylight-saving time — it computes correctly. On three independent test births spanning three United States timezones — Eastern daylight, Central standard and Alaska standard — it reproduces the Moon's nakshatra and pada and the ascendant exactly as juno.date's own engine, which uses the IANA timezone database for historical DST. Of the tools we have reviewed so far, it is the first that gets everything we checked right.

1. Why document correctness

Our earlier reviews flagged real defects — a modern Tamil almanac that omits daylight-saving correction, and a traditional site that over-corrects for longitude. It would be unfair, and untrue, to leave the impression that every tool is flawed. A review series only has credibility if it also names the tools that are right. This is one.

2. The test births — probing for blind spots

A single test can pass by luck. To probe specifically for the errors we have found in other tools — a forgotten daylight-saving offset, a mishandled far-from-India longitude, a timezone quietly defaulted to India — we used three births, in three different United States timezones, at both daylight and standard offsets. If a tool carries any of those blind spots, at least one of these births will expose it.

1 · Toledo, Ohio12 July 2006, 20:15:36 — Eastern Daylight Time (UTC−4). Probes daylight saving.
2 · Anchorage, Alaska22 December 2006, 20:44:01 — Alaska Standard Time (UTC−9). Probes an extreme western longitude and a deep standard offset.
3 · Overland Park, Kansas3 December 2002, 12:44:01 — Central Standard Time (UTC−6). Probes a mid-continent zone at midday.

3. Verification

Each birth was entered into drikpanchang's sidereal tool and, independently, into juno.date's engine (which converts local civil time to UTC through the IANA timezone database, so the exact historical DST rule applies). The two agree to the pada on both the Moon and the ascendant, in every case:

BirthMoon — drikpanchang → juno.dateLagna — drikpanchang → juno.date
Toledo (EDT)Makara / Shravana 4th → Shravana pada 4, MakaraDhanu / P.Ashadha 1st → Dhanu
Anchorage (AKST)Makara / Shravana 1st → Shravana pada 1, MakaraKataka / Ashlesha 4th → Kataka
Overland Park (CST)Vrischika / Anuradha 3rd → Anuradha pada 3, VrischikaKumbha / Shatabhisha 4th → Kumbha

Side by side, to the decimal. drikpanchang reports the Moon to arcminutes; juno.date reports it to two decimals of a degree, computed from the newer, more accurate JPL DE440 ephemeris (drikpanchang's Swiss Ephemeris ships the older DE431). Across all three cases the two agree to within a hundredth of a degree:

Birthdrikpanchang — Moonjuno.date — Moondifference
Toledo (EDT)Makara 22°10′  (292.17°)292.18°0.01°
Anchorage (AKST)Makara 10°35′  (280.58°)280.59°0.01°
Overland Park (CST)Vrischika 10°14′  (220.23°)220.25°0.02°
drikpanchang — Toledo, 12 July 2006 20:15:36: Lagna Dhanu / Purva Ashadha, Chandra Makara / Shravana.
1 · Toledo, EDT — Chandra in Makara (Shravana, 4th pada) and Lagna in Dhanu, matching juno.date. Captured 9 August 2026.
drikpanchang — Anchorage, 22 December 2006 20:44:01: Lagna Kataka / Ashlesha, Chandra Makara / Shravana.
2 · Anchorage, AKST (UTC−9) — Chandra in Makara (Shravana, 1st pada), Lagna in Kataka. A deep western offset, handled correctly. Captured 9 August 2026.
drikpanchang — Overland Park, 3 December 2002 12:44:01: Lagna Kumbha / Shatabhisha, Chandra Vrischika / Anuradha.
3 · Overland Park, CST — Chandra in Vrischika (Anuradha, 3rd pada), Lagna in Kumbha. Captured 9 August 2026.
Precision is not accuracy. We display a Moon longitude to two decimals and drikpanchang to arcminutes, but more digits do not make either tool more accurate. In fact drikpanchang runs the Swiss Ephemeris (derived from NASA/JPL data) with the official Lahiri ayanamsa — sub-arcsecond, and the stronger reference; our engine is accurate to roughly an arcminute. The residual differences above are hundredths of a degree, comfortably inside a single pada. This is mutual corroboration — two independent engines agreeing on the nakshatra, pada and rasi — not a precision contest, and we claim no superiority from an extra decimal.

4. What the three cases rule out

The ascendant advances about 15° per hour, so an hour's timing error moves it a half-sign. In the Toledo case, had drikpanchang used standard EST instead of the correct summer EDT, the birth instant would shift an hour and the lagna would leave Dhanu — it does not. The Anchorage case (UTC−9) would be grossly wrong if the tool defaulted to IST or any near-India zone; it is exact. The Overland Park midday case pins the standard Central offset. Together they close off the daylight-saving, wrong-longitude and defaulted-timezone blind spots at once — and the Moon's pada agrees in all three for the same reason.

5. Location and timezone

The ascendant is place-dependent: the same instant yields different lagnas at different coordinates. Three different lagnas, each correct for its city's latitude, longitude and civil timezone, confirm the tool uses the birthplace's actual location and local zone — not a fixed or India-defaulted one.

6. What else it does well

Beyond correct time handling, drikpanchang computes the full navagraha chart — all nine grahas with sidereal longitude, nakshatra, pada and sub-lord, plus the rasi chart — using drik (observation-corrected) calculations. That is more than a Moon-and-lagna summary: it is a complete birth chart, and the parts we can independently verify are exact.

7. Verdict

On location, local timezone and daylight saving — the three things that most often go wrong — drikpanchang is correct. It is, so far, the first reference in this series to pass every check we ran. Where other tools need a caveat, this one earns a recommendation: for a full sidereal chart with trustworthy time handling, it is a sound choice.

8. Where juno.date now stands

On the numbers, we now stand level with drikpanchang. Across the three edge cases above — three timezones, daylight and standard, one of them Alaska at UTC−9 — our Moon and lagna agree with it to within an arcminute, on both the nakshatra/pada and the rasi. And juno.date computes the Moon from NASA/JPL's current DE440 ephemeris (2020) — a newer release than the DE431 that the widely used Swiss Ephemeris — and therefore drikpanchang — still ships. Because each JPL release refines the one before it, DE440 is the more accurate model; so on the source data itself, juno.date holds the edge. The gap is far too fine to move a nakshatra or rasi, so both are trustworthy — but it is fair to say juno.date computes the same charts as the established authority from a more accurate, more current ephemeris, and then goes a step further in what it does with them.

A panchang is not a matchmaker, and drikpanchang does not claim to be one. It excels at what it sets out to do — an accurate almanac and a precise planetary chart for a reader who can already interpret one. By design it presents the raw positions in a table and leaves the reading to you: it does not consolidate the birth into a single, plain-language Jātakam laid out in the familiar chart boxes, and it does not compare two births at all — there is no porutham, gun milap or dosha matching. That is simply a different job from the one it does so well.

It is also, quietly, where juno.date focuses. We take the same correctly-computed birth data — held to the same insistence on getting the time right — and add the interpretation layer on top: a consolidated Jātakam, and a side-by-side compatibility match across every regional tradition. Different tools for different needs; we are glad to point to a good one, and to build on the part it leaves to the reader.

Method. One birth (Toledo, Ohio; 15 June 1997, 20:46 local) was entered into drikpanchang's sidereal planetary-position tool and into juno.date's engine, which converts local civil time to UTC using the IANA timezone database (so historical daylight-saving rules apply automatically) and assigns nakshatra/pada/rasi by dividing the 360° sidereal circle into 27/108/12 equal arcs, with the ascendant from closed-form spherical astronomy. Comparison is of the time-critical quantities juno.date computes (Moon nakshatra + pada, and lagna). These figures were produced by juno.date's own analysis and document drikpanchang as of the date above.