Accuracy of Tithi and Sunrise Computations in Two Vaishnava Calendar Engines:
Vaishnava Calendar for ISKCON versus GCAL, Validated against the JPL DE421 Ephemeris

1. Introduction

A tithi is the time the Moon needs to gain 12° of ecliptic longitude on the Sun. There are thirty tithis in a synodic month, and they last between about 19 and 26 hours. In the Gaudiya Vaishnava calendar a civil day takes the name of the tithi current at local sunrise. Because tithis and solar days are of different length, a tithi sometimes contains no sunrise (it is omitted, Kshaya), and sometimes contains two sunrises (it is repeated, Vriddhi). Ekadashi fasts, Mahadvadashi rules and the major festivals are defined in these terms.

The determining quantity is therefore the sign of the difference between two instants: the start of a tithi and sunrise. Tithi boundaries are distributed uniformly over the day. With about 371 boundaries per year, a systematic error of δ seconds in the boundary times moves on average

N_wrong ≈ N_boundaries · |δ| / 86 400 s (1)

boundaries across a sunrise. Over 17 years (6 307 boundaries), an error of 100 s gives about 7 wrong days per location, and an error of 5 s gives about 0.4. Sunrise errors act in the same way. Accuracy at the level of seconds is therefore not an academic refinement: it decides on which day thousands of people fast.

This report documents a validation carried out in 2026 while the test suite of the Vaishnava Calendar for ISKCON application was being refactored. A long-standing list of unexplained “Kshaya/Vriddhi” disagreements between the application and GCAL had been kept as accepted deviations. Their investigation led to an independent reference (JPL DE421), to the correction of four defects in the application, and to the error budget of GCAL presented in Section 5.

2. The two engines

GCAL (Gaurabda Calendar) was written by Gopalapriya das (ISKCON Bratislava) and calculates observances according to the standards of the ISKCON GBC Vaishnava Calendar Committee. It has been published as Windows (C++ and .NET), iOS, JavaScript and Python editions [1–5, 16, 17]. According to the author's web site [15] (section “GCAL application”), the development has stopped:

“Application is not available due to inactive developer account. It needs to be transfered to any suitable active developer account. After that, the app will be available again. The GBC Vaishnava Calendar Comitee is working on successor application.”

We examined six editions (Table 1a). The Python edition was measured against JPL; the others were compared with it as described in Section 3.5. The GCAL astronomy is self-contained: a tabulated mean solar longitude with a two-term equation of the centre, a 60-term lunar series following Meeus [7, ch. 47], and a four-term nutation. In every edition the tithi boundaries are found by the functions GetNextTithiStart and GetPrevTithiStart.

The repository gopa810/GCAL-12-outdated [3] was not examined. The .NET directories GCAL.Base and GCAL.Base-old contain byte-identical astronomy files.

Vaishnava Calendar for ISKCON (Android, package com.acd.calendar) [18] is developed independently by Abhay Charan das. Its astronomy is the AstroLib library by Mark Huss [6], which implements Meeus' Astronomical Algorithms [7]: VSOP87 for the Earth, the Meeus lunar theory and an iterative rise/set search. The calendar logic (Masa, tithi, Kshaya/Vriddhi, Ekadashi and Parana) is its own.

Both engines therefore belong to the same family: analytical series from Meeus without a numerical ephemeris. Until 2026 the Android application was tested only for agreement with GCAL, so a shared or similar systematic error could not be detected.

3. Data and methods

3.1 Reference

The reference is the JPL Development Ephemeris DE421 [8], evaluated with skyfield 1.55 [9]. A tithi boundary is the instant at which the apparent geocentric elongation of the Moon from the Sun, in ecliptic longitude of date, is a multiple of 12°. Apparent positions include light time, aberration and nutation. UTC is converted to TT with the IERS values of ΔT built into skyfield. Boundaries are found by root finding to 1 ms. Sunrise is the instant at which the upper limb of the Sun crosses the horizon with standard refraction, i.e. the centre of the Sun is at −0.8333°, for an observer at sea level. GCAL uses the same convention (eventdef = 0.01454 = sin 0.833°).

3.2 Locations and period

The period is 6 208 civil days from 1 March 2010 to 27 February 2027 (Gaurabda 524–540). It contains 6 307 tithi boundaries in each city. Local times include daylight saving time.

3.3 Data sets

For every city and every engine two files were produced in the same format (Section 10):

• per tithi: one line per tithi boundary: 2010-03-01 05:58:46 18:32:01 Dvitiya (local date, sunrise of that date, start of the tithi, name of the tithi that begins);
• per day: one line per civil day: 2010-03-01 Pratipat (the tithi at local sunrise).

The JPL files are rounded to the nearest second. The GCAL files are produced by the GCAL Python edition, which truncates seconds; 0.5 s was added before comparison. The values of the Vaishnava Calendar for ISKCON were taken from its built-in test kit, which compares every boundary and every sunrise with the reference (187 443 checks).

3.4 Error decomposition

For GCAL, the Moon and Sun longitudes that its tithi search (GCTithi.GetNextTithiStart) uses were evaluated at the true (JPL) boundary instants and compared with the apparent JPL longitudes. An elongation error ΔE is converted to a time error by

Δt = −ΔE / (dE/dt) (2)

where dE/dt is the instantaneous rate of the elongation (about 0.5″/s). A positive Δt means that the engine reports the boundary later than it occurs. The total ΔE was split into the terms listed in Table 5.

3.5 Comparison of the GCAL editions

The C++ editions were compared numerically. From the original sources we extracted GetNextTithiStart, GetPrevTithiStart and every function they call (date arithmetic, GetSunLongitude with its tables, the lunar series, the nutation and the mathematical helpers). The code was compiled unchanged with g++ on Linux; only the MFC headers were replaced by minimal class declarations. Both binaries and the Python edition then searched each of the 6 307 Mayapur boundaries forwards (from 0.3 day before) and backwards (from 0.3 day after), 12 614 searches in all.

No compiler or runtime was available for the .NET, JavaScript and iOS editions. For these, the code path of the tithi search was compared with the Python edition function by function: the time argument, the solar formula, the nutation, the lunar series and the search. All numerical tables (the 660 integer coefficients of the lunar series and the solar tables) were compared by script.

4. Results

4.1 Start of the tithi

^a Measured with the Python edition; the C++ editions of 2015 and 2019 give the same boundaries to 1 µs, and the .NET, JavaScript and iOS editions contain the same code (Section 5.3). The .NET edition rounds to the second instead of truncating, so its printed times are on average 0.5 s later than those of the other editions; the values in this table already contain the +0.5 s correction of Section 3.3. The 2026 values were measured after the corrections of Section 6. The “before” values use the same code without them.

4.2 Sunrise

The sunrise of both engines is accurate to a few seconds, with one exception: before 2026 the application took the sunrise of the wrong day in the time zones where sunrise falls close to 00:00 UTC (Section 6, item 4). The “before” column is a sample of every 15th day.

4.3 Consequences for the calendar

^a Reconstructed from the per-boundary differences recorded by the test kit; days within two days of a DST change are excluded. ^b Dnipro, 1 September 2019: the tithi begins at sunrise to the second (margin 0 s), so the result is decided by rounding.

On average GCAL assigns the wrong tithi to a civil day about once every two years in each location. The number of repeated (Vriddhi) tithis differs by at most one per city: 189/188 in Mayapur and 194/195 in Melbourne (JPL/GCAL). Every wrong day is a candidate for a festival or a fast on the wrong date.

Example. In Mayapur on 22 October 2010 Purnima begins 91 s before sunrise (JPL, 05:35:08 against sunrise 05:36:39), and it is still current at the next sunrise. It is therefore a Vriddhi Purnima, which by the Pakshavardhini rule moves the preceding Ekadashi fast (Pashankusha) to Dvadashi. The application before 2026 computed Purnima 110 s too late, i.e. after sunrise; it found no Vriddhi and gave the fast one day earlier. GCAL places the start of Purnima at 05:35:37, 60 s before its sunrise. The Ekadashi results that changed with the 2026 corrections (14 of 10 128 checks), as far as they were examined, are cases of this kind: a tithi boundary within about two minutes of sunrise.

5. Anatomy of the GCAL error

5.1 Error budget of the tithi start

Residual measured − sum: mean −0.1 s, standard deviation 1.8 s. The budget explains the GCAL error completely within the resolution of its output.

ΔT. The lunar theory is a function of Terrestrial Time; civil time is UTC. Between 2010 and 2027 the difference TT − UT grew from 66 to 69 s. GCAL uses the Julian day in UT as the argument of the lunar series. The Moon is therefore taken at the position it had about 68 s earlier, and boundaries are reported about 74 s late (the factor 13.2/12.2 is the ratio of the lunar to the elongation rate).

Aberration. Because light from the Sun takes 8.3 minutes to reach the Earth, the Sun is seen 20.5″ behind its geometric position. The visible elongation is therefore larger than the geometric one, and boundaries occur about 40 s earlier than the geometric calculation predicts. Meeus applies the correction in the apparent solar longitude [7, ch. 25]. GCAL does not.

Inconsistent nutation. Before the conversion to equatorial coordinates, eclipticalToEquatorialCoords adds the nutation in longitude Δψ (±17″) to the Moon. The tithi search, however, takes the Sun from GetSunLongitude, which contains no nutation. Nutation cancels in a difference of two longitudes only if it is applied to both. Applied to one, it becomes an error of ±41 s with the 18.6-year period of the lunar node. This term is the main cause of the slow drift of the GCAL error from year to year (Table 6).

Solar theory. GetSunLongitude interpolates a table of mean longitudes given to 0.001° and adds 1.915 sin M + 0.02 sin 2M. Planetary perturbations, the secular change of the coefficients and the higher terms are omitted. The result is an error of up to 41″, or −90 to +52 s of tithi time.

Lunar series. The 60-term series of Meeus ch. 47 is accurate to about 10″, or about ±20 s of tithi time. The same series is used in AstroLib. Its residual is the same in both engines (Table 2 and Table 5).

5.2 Other observations in the GCAL code

Our reading of the sources found the following properties. Unless stated otherwise, they are common to all editions.

• Different solar models in different places. Sunrise (SUNDATA.SunCalc), the tithi at sunrise (GCDayData.DayCalc) and the tithi boundaries (GetSunLongitude) each use their own solar model. In our data the results remained consistent with each other: the per-day tithi agreed with the per-tithi boundaries on all days except the first.
• Truncated seconds. All output times are floored, which introduces a bias of −0.5 s. The exception is the .NET edition, which rounds to the nearest second (Convert.ToInt64 in TResultCoreEvents.cs).
• Daylight saving time by date. DST is a flag for the whole civil day, derived from simplified month/weekday rules rather than from a time-zone database. On the day of a change, times before the actual switch instant are reported with the new offset, i.e. one hour off. The iOS edition takes the DST offset from the system time-zone database, but it too decides it once per civil day (at noon).
• Kshaya detection compares the tithis at consecutive sunrises and assumes that exactly one tithi was skipped.
• In the Python edition, SetAyanamsaType() lacks a global declaration and has no effect. The ayanamsha does not influence the tithi.
• In the Python edition, a wrong test in MahadvadasiCalc suppresses the Vyanjuli and Pakshavardhini Mahadvadashis in the bright fortnight in many cases. This moves the fast by one day 48 times in our five cities (Appendix A.3). The other editions are not affected.
• GetPrevTithiStart searches backwards for the most recent boundary. All editions find the same instant, but they return different tithi numbers. The iOS edition returns the tithi that begins at the boundary; the other editions return the tithi that ends there. This is not a defect: the other editions never use the returned number, and the only iOS caller (the “Today” screen, which searches back from midnight) needs exactly the tithi that begins at the boundary.

GCAL computes sunrise well (Table 3): an error of 30″ in the solar longitude changes sunrise by only a few seconds. The weakness is entirely in the tithi boundaries, where the same error is multiplied by 1/(dE/dt), about 2 s per arcsecond.

5.3 The same defects in all editions

Table 5a lists, for every edition, the code that produces each term of Table 5. The five sources of error are present in all of them, written in the same way. Only the language differs.

^a The C++ 2019 edition contains a ΔT function (GCDynamicTime) and a VSOP87-based solar position (GCMeeusEarth, GCAstroEngine), but they are called only from the eclipse module, whose only use is commented out. ^b The .NET edition contains VSOP87 as well, but the astronomy is fixed to the Meeus code path (GCCoreAstronomy.System = Meeus), and an alternative solar formula in C++ 2019 is marked “not used” by its author. The 31-term nutation exists in every edition but is disabled by a constant (if (1), LowPrecisionNutations = true, CALC_PRECISION_STYLE_LOW).

The numerical comparison of the C++ editions is exact: in all 12 614 searches both C++ binaries found the same tithi as the Python edition, at the same instant within 1 µs, and printed the same second. Against the GCAL reference file (produced with searches that start at sunrise) all three agree to ±1 s; the remaining one-second differences come from the start point of the bisection, whose last step is 0.04 s. The small differences found in the source (how the date rolls over a day, whether the Julian day is accumulated or recomputed at each step) do not change any result.

The error budget of Table 5 and the 40 wrong civil days of Table 4 therefore describe every GCAL edition, not only the Python port: the Windows programs of 2015 and 2019, the .NET desktop program, the iOS application and the JavaScript library all compute the tithi boundaries about 95 s late, with the same slow drift (Table 6). Differences between the editions are possible only in the presentation (rounding of seconds, DST) and in the calendar rules, not in the astronomy.

6. Errors found and corrected in the Vaishnava Calendar for ISKCON

The comparison with JPL revealed four defects in the application. All were corrected in 2026.

1. ΔT omitted in LunarCalc.ageOfMoonInDays (AstroLib): the Julian day in UT was passed to VSOP87 and to the lunar theory, which expect TT. A function AstroOps.deltaT was added: polynomials of Espenak and Meeus for 1900–2000 [10], the IERS values for 2000–2030 [11], and an extrapolation beyond.
2. Solar aberration omitted in the same function. The term −20.4898″/R is now subtracted from the solar longitude. Items 1 and 2 together amount to 109 s. The measured bias was 110 s; after the correction the residual bias is +0.7 s.
3. Stale precomputed table. The start of the first Pratipat of each year from 1894 to 2114 is taken from a precomputed table, which had been generated with the old formula. It was regenerated, and the test kit now checks it against the live calculation.
4. Sunrise of the wrong day. When sunrise falls close to 00:00 UTC (Mayapur, UTC+5:30; Melbourne, UTC+10/+11), the old code took the sunrise of the next day and subtracted 24 hours. This gave an error equal to the daily change of the sunrise time: up to 58 s in Mayapur and 94 s in Melbourne. Sunrise and sunset are now searched in a 24-hour window that begins at local midnight.

After the corrections, the 22 accepted “Kshaya/Vriddhi” deviations from GCAL disappeared against the JPL reference. They had all been caused by the boundary bias, not by the Kshaya/Vriddhi logic. The test kit now needs no list of accepted deviations. The only remaining classes are boundaries within 30 s of sunrise, which are treated as undecidable, and times inside the hour that is repeated or skipped at a DST change.

7. Discussion: why hand-made series are a dangerous path

Meeus' algorithms are not wrong. The book states each of the corrections that were missing here: dynamical time, aberration and nutation, together with their magnitudes [7]. The danger lies in using them as a collection of formulas without an external check.

1. The errors are systematic, not random. A missing correction of 1–2 minutes affects every boundary in the same direction. Spot checks (“the time agrees to the minute”) do not reveal it, because the published tables were produced by programs of the same family.
2. The consequences are rare but certain. By Eq. (1), a bias of 100 s produces about one wrong day every two years in each location. With hundreds of locations and many users, festivals and fasts on the wrong day occur every year.
3. Agreement between engines proves nothing. Before 2026 the application was tested only against GCAL. Two engines with errors of +95 s and +110 s agree with each other to a few tens of seconds, and both are wrong. The investigation succeeded only because an independent ephemeris was introduced.
4. Regression tests protect the past, not the truth. The Ekadashi reference of the application had been generated by its own earlier version. It preserved the old bias: the 14 changes after the correction were improvements, but a regression test reports them as failures.
5. Small inconsistencies add up. No single defect of GCAL is large. Its 95 s come from five terms of 2–74 s each, two of which (nutation and the solar theory) vary slowly over years and conceal the bias.

8. Recommendations for future calendar engines

The successor of GCAL, which the GBC Vaishnava Calendar Committee is preparing, can avoid all of the issues in Section 5 by following these points from the start.

9. Future work

The remaining error of the application (σ 5 s, maximum 22 s) comes from the truncated lunar series. Further improvements are possible, in order of increasing cost, eventually up to “when we have supercomputers”:

• the complete lunar theory ELP/MPP02 [14], or a compact Chebyshev representation of DE440 embedded in the application (error below 0.1 s);
• the light time of the Moon (≈ 1.4 s of tithi time);
• UT1 instead of UTC, and ΔT predictions with stated uncertainty for dates years ahead;
• sunrise with refraction computed from local temperature and pressure, the elevation of the observer and the real horizon profile; these can change sunrise by tens of seconds, more than the ephemeris error;
• a probabilistic presentation of undecidable days: the likelihood that the observance falls on each of two dates;
• a run of the .NET, JavaScript and iOS editions of GCAL, for completeness; their code is identical to the measured editions (Section 5.3), so no different result is expected.

For the rule-based part of the calendar (Ekadashi, Mahadvadashi, festivals) the next step is a comparison of the rules themselves. In the example of Section 4.3 both engines see a Vriddhi Purnima, yet they derive different fast days from it. That difference is a question of interpretation for the Calendar Committee, not of astronomy.

10. Data availability and reproducibility

All data sets used in this report are available as Android string-array resources (XML). The GCAL files were produced with the GCAL Python edition and its tests/generate_test_arrays.py. The JPL files were produced with generate_jpl_reference.py (skyfield 1.55, DE421). The error decomposition is performed by gcal_error_analysis.py. The comparison of the C++ editions with the Python edition (Section 3.5) is performed by gcal_editions_crosscheck.py, which extracts the tithi search from the original C++ sources and compiles it with g++; the GCAL sources themselves are not part of the data set. The Ekadashi fast days of Appendix A are computed by arunodaya_analysis.py from these files and the GCAL calendar data.

Each per-tithi file has 6 307 lines and each per-day file 6 208 lines. The JPL files can be regenerated at any time with the script; DE421 (17 MB) is downloaded automatically.

11. References

1. Gopalapriya das. gaurabda-calendar: Python library for calculating Panchanga calendar with vaisnava events. github.com/gopa810/gaurabda-calendar; package pypi.org/project/gaurabda.
2. Gopalapriya das. Gaurabda Calendar for JavaScript. github.com/gopa810/gaurabda-js.
3. Gopalapriya das. GCAL for Windows .NET platform. github.com/gopa810/GCAL-12-outdated.
4. Gopalapriya das. GCAL .NET for Desktop. github.com/gopa810/GCAL-Net-Desktop.
5. Gopalapriya das. GCAL for iOS. github.com/gopa810/gcal-ios.
6. Huss, M. AstroLib, Java astronomy library. mhuss.com/AstroLib.
7. Meeus, J. Astronomical Algorithms, 2nd ed. Willmann-Bell, Richmond, 1998.
8. Folkner, W. M., Williams, J. G., Boggs, D. H. The Planetary and Lunar Ephemeris DE 421. JPL IOM 343R-08-003, 2008.
9. Rhodes, B. Skyfield: High precision research-grade positions for planets and Earth satellites. Astrophysics Source Code Library, ascl:1907.024, 2019. rhodesmill.org/skyfield.
10. Espenak, F., Meeus, J. Polynomial Expressions for Delta T. NASA Eclipse Web Site. eclipse.gsfc.nasa.gov/SEhelp/deltatpoly2004.html.
11. International Earth Rotation and Reference Systems Service (IERS). Earth orientation data, ΔT and UT1−UTC. www.iers.org.
12. Park, R. S., Folkner, W. M., Williams, J. G., Boggs, D. H. The JPL Planetary and Lunar Ephemerides DE440 and DE441. Astronomical Journal 161:105, 2021.
13. Astrodienst. Swiss Ephemeris. www.astro.com/swisseph.
14. Chapront, J., Francou, G. The lunar theory ELP revisited. Introduction of new planetary perturbations. Astronomy & Astrophysics 404, 735–742, 2003.
15. Gopalapriya das. Application status (Bhaktivedanta Vedabase, GCAL). www.gopal.home.sk/appstatus.html (accessed October 2026).
16. Gopalapriya das. GCAL for Windows, version 11 (C++, gcal_11c). github.com/gopaladasa/GCAL-for-Windows/tree/master/gcal_11c (the sources have since been removed from the repository; a source archive of 20 August 2019 was used).
17. GCAL C++ source code, GCAL 1.4.3 line (project VCal5beta), source archive of 5 July 2015 (SamskaraTimes-master), private copy.
18. Abhay Charan das. Vaishnava Calendar for ISKCON, Android application. play.google.com/store/apps/details?id=com.acd.calendar.
19. Abhay Charan das. Fix MahadvadasiCalc: Vyanjuli and Pakshavardhini Mahadvadashis skipped in Gaura paksha. Pull request #6, gaurabda-calendar, 11 October 2026. github.com/gopa810/gaurabda-calendar/pull/6.

Appendix A. Ekadashi fast days: the Arunodaya rule and a defect of the Python edition

A.1 The Arunodaya rule

A civil day takes the tithi current at sunrise (Section 1). The Ekadashi fast uses a second instant as well: Arunodaya, 96 minutes before sunrise. If Dashami is still current at Arunodaya, the Ekadashi is “viddha” (mixed with Dashami), and the fast moves to the next day. Both engines apply this rule with a fixed interval of 96 minutes (GCAL: sunrise_deg − 24° in SUNDATA.SunCalc and nTithiArunodaya in TCalendar.EkadasiCalc; Vaishnava Calendar for ISKCON: two muhurtas of 48 minutes in Fast.java).

The start of Ekadashi falls within a few minutes of Arunodaya about as often as a tithi boundary falls near sunrise. The bias of the GCAL tithi times therefore decides some fasts through Arunodaya as well. Table 4 does not count these cases, because the tithi at sunrise is correct on those days.

A.2 Method and results

The Ekadashi rules of GCAL (TCalendar.MahadvadasiCalc and TCalendar.EkadasiCalc, including the parana day of CalculateEParana) were reimplemented and applied in the same way to two inputs: the tithi at sunrise, the sunrise and the tithi boundaries of the GCAL calendar, and the same quantities from JPL DE421. The tithi at Arunodaya is taken at sunrise minus 96 minutes in both. The naksatra Mahadvadashis (Jaya, Jayanti, Papa-nasini, Vijaya) need the naksatra and were left out for both inputs. The reimplementation was checked against the GCAL calendar itself: with the GCAL input it reproduces all 2 098 Ekadashi fast days of the five cities that are not near a naksatra Mahadvadashi.

By Eq. (1), a bias of 95 s moves 2 100 × 95 / 86 400 ≈ 2.3 Ekadashi starts across Arunodaya; 2 were observed. The wrong tithi days of Table 4 did not move any Ekadashi fast in this period.

In both cases the Ekadashi is pure according to JPL DE421 and the fast falls on the day of Ekadashi itself. GCAL reports the start of Ekadashi 2–3 minutes late. It therefore finds Dashami at Arunodaya, declares the Ekadashi viddha, and moves the fast to the next day. The GCAL calendar data confirm these fast days (Saphala Ekadashi on 30 December 2021 in New York, Apara Ekadashi on 24 May 2025 in Melbourne). The margins (47 and 66 s) are well above the remaining error of the corrected Vaishnava Calendar for ISKCON (at most 22 s in the tithi times and 3 s in sunrise, Tables 2 and 3), so it decides the Arunodaya question for these two Ekadashis as JPL does.

A.3 A defect of the Python edition in MahadvadasiCalc

The reimplementation also exposed a defect in the rules of the Python edition. Before it tests for the Vyanjuli, Pakshavardhini and Suddha Mahadvadashis, MahadvadasiCalc checks for a naksatra Mahadvadashi. In the C++, .NET, iOS and JavaScript editions the test is a boolean function that returns false when there is none:

// C++ 2019, TResultCalendar.cpp:1439 (likewise C++ 2015, .NET VAISNAVADAY.cs:692, iOS GcResultCalendar.m:1325)
if (TITHI_GAURA_DVADASI == t.astrodata.nTithi && TITHI_GAURA_DVADASI == t.astrodata.nTithiSunset && IsMhd58(nIndex, nMahaType))
// JavaScript, Vaisnavaday.js:586
... && ((nMahaType = t.IsMhd58()) != MahadvadasiType.EV_NULL))

The Python port compares the returned type with zero instead:

# Python, gaurabda/TCalendar.py:747-748
nMahaType = self.IsMhd58(nIndex)
if (TITHI_GAURA_DVADASI == t.astrodata.nTithi and TITHI_GAURA_DVADASI == t.astrodata.nTithiSunset and nMahaType!=0):

Since EV_NULL = 0x100, the condition is always true. Whenever Gaura Dvadashi is current at both sunrise and sunset, the branch is taken with “no Mahadvadashi”, and the Vyanjuli and Pakshavardhini rules are never reached. The fast then falls on Ekadashi instead of on the Mahadvadashi the next day. In the five cities this happened 48 times in 17 years (28 Vyanjuli and 20 Pakshavardhini), about once every two years in each location (Table A1, last column). The correction is one line: nMahaType != EV_NULL. It was submitted to the maintainer of the Python edition on 11 October 2026 as a pull request [19]. The tithi data used elsewhere in this report are not affected.

A.4 Recommendations to the maintainers of GCAL

GCAL is still in use, and its successor is being prepared. The following changes would remove every defect found in this report. Items 1–4 are the components of Table 5; together they would bring GCAL to the accuracy of the corrected Vaishnava Calendar for ISKCON (a standard deviation of about 5 s).

1. Evaluate the lunar series in Terrestrial Time (add ΔT). The C++ 2019 edition already contains a ΔT table (GCDynamicTime); it is used only by the disabled eclipse module.
2. Subtract the annual aberration (−20.5″) from the solar longitude.
3. Apply the nutation in longitude to both the Moon and the Sun, or to neither.
4. Replace the tabulated solar longitude with the VSOP87 theory, which is already part of the C++ 2019 and .NET editions.
5. In the Python edition, change nMahaType!=0 to nMahaType!=EV_NULL in TCalendar.MahadvadasiCalc.
6. Validate every edition against JPL DE440 or DE421 before each release, with the data and scripts of Section 10.

Until these corrections are made, the users of GCAL in the five cities examined here will see, over 17 years, 40 civil days with the wrong tithi (Table 4) and 2 Ekadashi fasts on the wrong day (Table A2). Users of the Python edition will see a further 48 fasts on Ekadashi instead of on Mahadvadashi (A.3).

← Back