We don't only document what tools get wrong. When one gets it right, we say so — and here is one that does.
Published 9 August 2026. Behaviour and figures document the tool as of this date.
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.
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.
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:
| Birth | Moon — drikpanchang → juno.date | Lagna — drikpanchang → juno.date | |
|---|---|---|---|
| Toledo (EDT) | Makara / Shravana 4th → Shravana pada 4, Makara | Dhanu / P.Ashadha 1st → Dhanu | ✓ |
| Anchorage (AKST) | Makara / Shravana 1st → Shravana pada 1, Makara | Kataka / Ashlesha 4th → Kataka | ✓ |
| Overland Park (CST) | Vrischika / Anuradha 3rd → Anuradha pada 3, Vrischika | Kumbha / 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:
| Birth | drikpanchang — Moon | juno.date — Moon | difference |
|---|---|---|---|
| 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° |



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.
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.
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.
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.
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.