juno.date · Research

srirangaminfo: Traditional Depth in Tamil Matching — Credit, and the Limits

Genuinely strong, and correct for Indian births — with two honest limits: a birthplace search that buries big cities, and a Local-Mean-Time habit that only bites abroad.

Abstract. srirangaminfo.com is one of the more traditionally faithful Tamil marriage-matching sites, and on the astronomy that matters it earns real credit: for births inside India it converts the clock through IST correctly and computes the janma nakshatra to the pada — we verify this against a JPL-grade engine on a demanding boundary pair. Its strengths are genuine: a gendered, fine-grained yoni scheme that yields broader, more forgiving matches, and a direct nakshatra + rasi engine that sidesteps birth time. Two limits temper it. First and most consequential, its birthplace search does not rank by population, so major cities are buried under obscure same-named villages — a search for “Dubai” surfaces only tiny Indian hamlets, never Dubai, UAE — inviting a wrong-place chart. Second, for foreign births it substitutes exact-longitude Local Mean Time for the birthplace’s civil timezone and daylight-saving rule — confirmed by the fractional timezone it prints on screen (e.g. −4.68 for Portland, Maine, instead of the civil −4:00). juno.date ranks places by population (Dubai resolves first) across ~235,000 worldwide, and converts every birth through the IANA timezone database.

1. Introduction

Where the modern Tamil almanacs aim for convenience, srirangaminfo aims for tradition. It generates the Tamil jathagam and grades marriage compatibility across the classical ten-to-twelve poruthams, returning the familiar verdicts of Uthamam (excellent), Madhyamam (moderate) or Adharmam (poor). It retains features the lighter tools drop — the tree (Vriksha) porutham as the twelfth, and, most importantly for matching quality, the older and finer yoni conventions of the temple tradition. For a family that wants a reading in the register of the srirangam panchangam, it is a natural home.

This review argues two things at once, and they are not in tension: that srirangaminfo's matching model is in important respects better than its modern competitors, and that its time model contains a self-inflicted error that is easy to trip over. The good news, developed at the end, is that the site's own design offers a clean way around the flaw.

2. Strengths

2.1 A gendered, fine-grained yoni scheme

The yoni (animal-temperament) porutham is where srirangaminfo most clearly outperforms the standard tools. Most online engines collapse the bovine animals into a single "cow" yoni and ignore the male/female attribute of each nakshatra. srirangaminfo keeps the finer classical Tamil scheme: the ox (எருது) and the cow (பசு) are distinct yonis, and each nakshatra carries a gender (ஆண்/பெண்). This is not decoration — it materially changes which couples are judged compatible.

2.2 Why finer granularity produces broader, better matching

Consider the tiger (புலி). In the merged scheme, the tiger's enemy is "cow" — and because the ox has been folded into cow, a tiger-nakshatra person is marked yoni-incompatible with every bovine-nakshatra person. That is a wide exclusion. In srirangaminfo's finer scheme, the tiger's true enemy is only the cow (பசு, i.e. Uttarabhadra/Uthirattathi), not the ox (எருது, i.e. Uttaraphalguni/Uthiram); and the gender rule further softens or sharpens the pairing. The enemy list is therefore narrower, the friend list broader, and fewer couples are rejected on yoni for no traditional reason. This is exactly the effect seen in the origin case (Sindhu × Vinayak): the ஆண் புலி–ஆண் எருது pairing (male tiger, male ox) is counted as friendly (நட்பு) in the srirangam scheme, but as an enemy "tiger–cow" pairing in the merged scheme. The finer granularity is not merely more detailed; it is more forgiving, and it aligns with the pragmatic traditional principle that a marriage should proceed when the weightier poruthams (Rajju, Nadi, Dina) hold.

In short: a narrower enemy list = a wider set of workable matches. For a family, a tool that does not reject an alliance on a technicality the tradition itself would waive is the more useful — and the more faithful — tool.

2.3 A direct nakshatra + rasi matching engine

srirangaminfo also provides a matching engine that accepts each partner's nakshatra and rasi directly, without asking for a full birth record. This is genuinely convenient: once a person's star and sign are known, the porutham grid can be produced immediately, and — crucially — this path bypasses the site's own time-conversion step entirely. As we will see, that makes it the recommended way to use the site.

2.4 Traditional completeness

Finally, the site carries the full traditional apparatus: the twelve poruthams including Vriksha, the Uthamam/Madhyamam/Adharmam grading, and the temple-tradition presentation that many Tamil families expect. For authenticity of convention — as distinct from precision of time — it is a reference point.

3. Credit where it is due: Indian births are computed correctly

Before any criticism, the record must be fair — and on the astronomy that matters, srirangaminfo is right for the births it is built for. We entered a deliberately hard boundary pair into its live matching tool and compared the output, quantity by quantity, with juno.date’s engine (which reads NASA/JPL’s DE440 ephemeris). It matched us to the pada.

The test pair. Girl — Ahmedabad, 10 Mar 1990, 13:57; Boy — Rajkot, 3 Sep 1991, 11:01. Both are boundary births, chosen so that even a ~40-minute time error would change the janma nakshatra — a demanding test of time handling.
srirangaminfo input form with the Ahmedabad girl and Rajkot boy
The couple as entered into srirangaminfo. Documented 10 August 2026.
Personsrirangaminfo showsjuno.date (JPL DE440)
Girl (Ahmedabad)Magha / மகம், 4th padaMagha, pada 4exact ✓
Boy (Rajkot)Mrigashira / மிருகசீரிஷம், 4th padaMrigashira, pada 4exact ✓
srirangaminfo output showing Magha and Mrigashira janma nakshatra
srirangaminfo’s computed charts: janma nakshatra Magam (Magha) for the girl and Mirugasirisham (Mrigashira) for the boy — 4th pada each, matching juno.date exactly. Note the timezone it used: +5:30 (IST). For Indian births there is no time-shift error, and it would be dishonest to imply one.

4. The real gap: the place search buries large cities

The limitation that actually bites is not the astronomy — it is finding your birthplace. srirangaminfo’s place autocomplete does not appear to rank matches by population (or it shows only the first handful), so well-known cities are buried beneath obscure same-named villages.

srirangaminfo place search for Dubai returns only small Indian villages, not Dubai UAE
Typing Dubai returns only tiny Indian hamlets — Dubaihri, Dubai Pura, Dubai Rajpur (Uttar Pradesh and Bihar villages). Dubai, UAE — a city of roughly three million, home to one of the largest Indian communities in the world — never appears. Documented 10 August 2026.

Whether Dubai is absent from the underlying list or merely ranked below a dozen namesake hamlets, the effect on the user is the same: they cannot readily select their real birthplace, and a less-savvy user may pick a wrong village hundreds of kilometres away — producing a chart for the wrong place, and with it a wrong ascendant and often a wrong match. A knowledgeable user can work around it — one can, for instance, choose nearby Sharjah as a stand-in for Dubai — but a service should not require that. This is exactly the pitfall juno.date removes by ranking birthplace suggestions by population: on juno.date, “Dubai” returns Dubai, UAE first. Our gazetteer holds ~235,000 places worldwide, resolving not only Dubai but mid-size towns such as Bangor, Maine — which srirangaminfo does not find at all — and, with an ongoing expansion, small Indian villages down to hamlet size.

5. Foreign births: a QA punch-list, offered in the spirit it was built

Everything in this section concerns foreign (non-IST) births only — for Indian births the engine is correct, as §3 shows. srirangaminfo is a sincere, tradition-faithful tool: its twenty-five poruthams are grounded in Tholkappiyar and Agastya, and its instinct to encourage families rather than reject them is a kindness, not a defect. So what follows is written the way one hands notes to a respected colleague — a QA punch-list, each item specific, reproducible, and paired with the screenshot that documents it. Our overall read: the tool is roughly 70% of the way to dependable diaspora use, and the remaining work is arithmetic and consistency, not tradition.

A. Time handling — the root cause. For a foreign birth, srirangaminfo prints the very timezone it used, and it is not the civil one.

srirangaminfo reports TimeZone -4.68 for Portland and +7.64 for Yuma, the exact longitude over 15, not the civil offset
Portland, Maine prints TimeZone −4.68; Yuma, Arizona prints +7.64. Those are the exact longitude ÷ 15 values (70.15°/15, 114.37°/15) — the birthplace’s Local Mean Time, not the civil EDT (−4:00) or MST (−7:00).
  1. Fractional Local Mean Time instead of the civil clock. For Detroit it uses longitude ÷ 15 = −5.54 h, not the civil −4:00 (EDT). People are born on the clock, not the sundial; the clock carries the country’s standard offset, and this discards it.
  2. Daylight Saving is not removed. On top of (1), the DST hour is left in, so a Detroit summer birth lands about 150 minutes late — comfortably enough to push the Moon into the next nakshatra.
  3. The timezone sign is inconsistent. In one match the same city prints −5.54 for the bride and +5.54 for the groom, and the ‘+’ version is actually used (computing the Moon ~9 hours early), not merely displayed.
Detroit couple: bride shown as Swati with TimeZone -5.54, groom shown as Avittam with TimeZone +5.54
Two Detroit births in one match: TimeZone −5.54 for the bride, +5.54 for the groom — same city, opposite sign. Both are the Local Mean Time value (83.2°/15), neither is the civil EDT (−4:00).

The net effect: a foreign Moon can be anywhere from tens of minutes to ~10 hours off, so the janma nakshatra changes whenever a birth falls near a boundary — and each nakshatra is only about a day wide.

A worked example (Detroit). Bride 13 Sep 1999, 02:20; groom 8 Sep 1995, ~10:00; both Detroit, both on EDT. Computed correctly, she is Chitra and he is Shatabhisha — an excellent match on the same JPL-grade table used throughout this review. srirangaminfo’s header instead shows her as Swati (Issue 1, ~150 min late) and him as Avittam / Dhanishta (Issue 2, wrong sign, ~9 h early). Only the bride’s shift reaches the verdict — see B(4) — and it is enough to move Dina, Yoni and Rajju from pass to fail.

B. Internal consistency.

  1. The star shown is not the star matched. For the Detroit groom the header and chart display Avittam (Dhanishta), yet every one of the twenty-five porutham rows is computed on Sadhayam (Shatabhisha) — which is, in fact, his correct star. A reader sees one nakshatra while the compatibility verdict was built on another.
  2. The same score is labeled two ways. The identical 7/11 result reads as “நட்சத்திர பொருத்தம் இல்லை” (no match) on the detail screen and as “மத்திமம்” (acceptable) on the shareable card.
  3. Lagna is computed on the same wrong time. The ascendant moves 15° an hour, so it is the most distorted point on the whole chart whenever the birth time is off.
srirangaminfo verdict screen reading no nakshatra compatibility at 7 of 11
The detail screen labels this run “no nakshatra compatibility” at 7/11; the shareable card for the same run badges it “மத்திமம்” (acceptable). A short consistency pass would reconcile the two.

C. Precision hygiene.

  1. Spurious precision. The Samudrika reading prints 10.054166666667 Cm — twelve decimals for a body measurement — and the timezone is given as −5.54. Precision far past what is meaningful can read as an accuracy that isn’t there.
  2. Ayanamsa reads −24.23 for 1999, about 0.4° above the standard Lahiri value (~23.85°) — small, but enough to tip a boundary case. This one is worth re-checking against the intended ayanamsa setting before acting on it.

Bottom line. None of the above touches the tradition or the rules, which are sound and generous. What stands between srirangaminfo and dependable diaspora use is a single area — foreign-birth time handling — plus a short consistency pass over the display-versus-engine star and the two verdict labels. It is a good tool, honestly built and right where most of its users are; the last 30% is arithmetic and QA, and every item above is reproducible and fixable. juno.date converts every birth through the IANA timezone database instead — the exact civil offset and daylight-saving rule for the place and year, applied automatically, with no precision checkbox to remember.

6. Practical guidance

The remedy follows directly from the site's own design. First, compute each partner's nakshatra and rasi correctly — either on srirangaminfo's jathagam page with the precision checkbox left off (civil offset), or with any engine that uses proper civil/clock time (DST-aware for foreign births). Then use srirangaminfo's direct nakshatra + rasi matching engine, which takes those values as input and never runs the time conversion at all. In this mode the family enjoys the site's excellent, forgiving traditional matching without exposure to the over-correction. As a one-line summary: srirangaminfo is a great matching site as long as you step away from its time conversion.

7. How juno.date addresses it

Our engine converts every birth using proper civil time — the clock offset of the birth's timezone, with DST applied for foreign births — and never applies a Local Mean Time re-correction to a clock-recorded input. At the same time, we adopt srirangaminfo's stronger matching conventions: the gendered, fine-grained yoni scheme (so male tiger and male ox are read as friends, not enemies) sits in our engine alongside the merged modern convention, and the two are shown side by side. The aim is to keep srirangaminfo's traditional depth while discarding the time error that compromises it.

8. Conclusion

srirangaminfo is, on the merits of its matching, one of the better Tamil tools: its gendered, fine-grained yoni scheme produces a broader and more faithful set of acceptable matches than the merged conventions, its enemy list is appropriately narrow, and its direct nakshatra/rasi engine is a genuine convenience. Its one real flaw is a Local Mean Time over-correction — a reach for a precision the clock-recorded input never held — which is, revealingly, optional on the jathagam page but forced in the matching tool. For births far from the 82.5°E meridian, or near a nakshatra or rasi boundary, that forced correction can change the star, the sign and the match. Used through its direct star/rasi engine, with the chart computed on civil time, the site's strengths come through cleanly and its one weakness disappears.

Methodology & data. Sidereal Moon longitudes were computed with the astronomy-engine ephemeris minus a fixed Lahiri ayanamsa of 23.83°. The "correct" conversion applied India's civil offset (UTC+5:30); the "srirangam" model applied the birthplace's Local Mean Time (longitude ÷ 15 hours). Nakshatra/pada/rasi were assigned by dividing the 360° sidereal circle into 27/108/12 equal arcs. City longitudes are standard values. These figures were computed by juno.date's own time-handling analysis.

Disclaimer. This review analyses computational behaviour for reference and is based on the site's publicly described method and observed checkbox behaviour; it is not a comment on the site's owners. Site behaviour and brand names belong to their respective owners and may change over time. — juno.date Research