Swiss Ephemeris 2.10.3: What Changed for Synastry?

What changed for chart readers in Swiss Ephemeris 2.10.3?

Swiss Ephemeris 2.10.3 names two changes: a fix to the search for historical lunar eclipses and an improved calculation of the Moon’s apparent magnitude when it is near the Sun. Neither change is described as a revision to ordinary planetary longitudes. So the release notes alone are not a reason to replace a Moon, Venus, or Mars sign placement, or a longitude-based synastry aspect. If two chart reports differ, check their calculation inputs and data files before changing the reading. The distinction is about what each calculation returns. In the Swiss Ephemeris Programmer’s Manual, swe_lun_eclipse_when() searches for lunar-eclipse events. The manual describes the magnitude improvement for large phase angles, when the Moon is close to the Sun. Magnitude here concerns how bright the Moon appears. A natal position, by contrast, is a coordinate such as ecliptic longitude; astrologers use that degree to place a body in a zodiac sign or compare its angular distance with another body. These are separate layers. A note about an eclipse search or apparent brightness does not, by itself, report a changed longitude. The wording also calls for care. The manual places the missed lunar eclipses between 776 and 967 CE. The upstream Swiss Ephemeris release entry gives 766 to 987 CE and says 74 of 506 eclipses were missed. Those records agree on the kind of fix, but differ on its stated span and count. For this chart question, the discrepancy is a reason to quote the records precisely, not to turn the section into an eclipse history. A version label still matters, but it is only one part of a calculation’s provenance. This change list identifies the functions and behaviors it addresses; it does not provide a full comparison proving every ordinary position output identical across builds. Nor does it establish that a particular chart service uses the same library, files, or settings as another. Keep the release in context: first identify whether the disputed result is an event search, a brightness value, or a planetary degree. Then ask whether the degree itself changed before revisiting the sign or aspect interpretation.

Sources: Swiss Ephemeris Programmer's Manual: 2.10.02 to 2.10.03 changes; Releases · aloistr/swisseph

Which part of a synastry input comes from a position calculation?

A position is a calculated coordinate. In the Swiss Ephemeris Programmer's Interface, the sequence starts with a birth date and a Julian day number, then a position function such as `swe_calc_ut()` returns values for the selected body under the supplied flags. For synastry, the coordinate most often compared is ecliptic longitude: a degree measured around the ecliptic. The calculation gives you that number. It does not, by itself, tell you what the contact means in a relationship. A sign label is a classification of longitude. In the familiar twelve-sign zodiac, each sign covers 30 degrees of the circle, so a longitude is assigned to the corresponding interval. If two chart outputs disagree, ask whether the Moon’s longitude differs or whether the reports classify the same longitude under different settings. A longitude-based aspect is another step. Take one person’s position and the other person’s position, find their angular separation, then compare it with an aspect angle such as a conjunction, square, or trine. The chosen orb sets how far from exact that contact may be and still count. Two readers can use the same calculated degrees yet label a borderline contact differently if they choose different orbs. That difference belongs to classification, not necessarily to the ephemeris calculation. This distinction matters when you compare Moon, Venus, and Mars. Those are the placements the Synastry Comparison Report interprets when supplied, with optional degrees and selected major aspects under its stated six-degree orb. A position service can calculate a degree; a report or astrologer then groups that degree by sign, measures contacts, and weighs their significance. The numerical output is one layer of the reading, not its whole judgment. The Swiss Ephemeris Programmer's Interface documents planetary-position functions separately from functions for lunar-eclipse searches and planetary phenomena. The version history also names the Moon’s apparent-magnitude calculation as a separate area. “Magnitude” describes apparent brightness; it is not the longitude used to assign a zodiac sign. An eclipse-search result identifies an event or its circumstances; it is not a natal placement. A release note mentioning the Moon can therefore concern a different calculation from the Moon degree in a synastry chart. When someone says an update changed a chart, make the claim specific. Is the Moon’s degree different, or only its sign label? Did the degree change, or did an aspect appear because the orb rule changed? That question separates a calculation difference from an interpretive classification.

Sources: swephprg programming interface; Swiss Ephemeris Programmer's Manual: 2.10.02 to 2.10.03 changes

Why are magnitude, eclipse search, longitude, and aspects different chart layers?

The Swiss Ephemeris Programmer's Manual separates planetary position functions, eclipse searches, and planetary phenomena into distinct parts of its interface. For synastry, a brightness estimate or eclipse-search fix does not by itself show that the Moon's zodiac longitude changed. An eclipse search asks when an event occurs and returns event timing or circumstances. The manual describes swe_lun_eclipse_when() as a function for finding a lunar eclipse. Swiss Ephemeris 2.10.3's version note says a bug in that search had caused some historical lunar eclipses to be missed. The upstream Swiss Ephemeris release entry also describes the missed-eclipse issue. This concerns locating events, not a new natal Moon position. The magnitude calculation answers another question: how bright does the Moon appear under its phase and viewing geometry? The manual describes swe_pheno() and swe_pheno_ut() as returning several planetary phenomena, including phase, elongation, apparent diameter, and apparent magnitude. The 2.10.3 entry says the Moon's magnitude calculation was improved for large phase angles, when the Moon is close to the Sun. That is a refinement to an apparent-brightness quantity. A chart's sign placement, by contrast, uses a position coordinate. A longitude-based synastry comparison uses each relevant planet's ecliptic longitude at each birth moment. A sign label is assigned from that coordinate under the chosen zodiac convention. An aspect compares the angular separation between two such positions with a selected aspect angle, then applies the chosen orb. The calculation gives the separation; astrological interpretation weighs what that contact means alongside the rest of each chart in the comparison. The Programmer's Manual documents position calculations separately from eclipse-search and phenomena functions. So the practical chain is position, then classification: longitude supplies the degree; sign and aspect labels follow from that degree and the reader's chosen rules. This distinction prevents a tempting but unsupported inference. The Moon appears in both 2.10.3 notes: one names an eclipse-event search, the other apparent magnitude near the Sun. Neither note identifies a change to ordinary natal longitude calculations or to the rules for assigning signs and aspects. A magnitude refinement therefore gives no direct reason to change a Moon sign or synastry contact. There is a limit to what a short change log can establish. It identifies named changes, not a complete test proving every other output identical across builds. If two chart reports disagree, compare the actual positions and the settings used to classify them. Ask which value changed: event timing, apparent magnitude, longitude, or only the sign/aspect label. That question keeps a software update in its proper layer and tells you what evidence would make it relevant to your synastry reading.

Sources: Swiss Ephemeris Programmer's Manual: 2.10.02 to 2.10.03 changes; swephprg programming interface; Releases · aloistr/swisseph

How should the version history be read without merging separate fixes?

Keep the 2.10.3 changes separate from the earlier 2.10.01 lunar correction. The Swiss Ephemeris Programmer's Manual places the 0.042-arcsecond figure in its entry for the change from 2.10 to 2.10.01. It describes an old bug in the lunar ephemeris when the Swiss Ephemeris flag was used: packing and unpacking used different J2000 ecliptic obliquities. The same entry says 2.10.01 added correct handling for JPL DE441, along with other fixes. Those are specific earlier changes. They are not measurements of what changed between 2.10.02 and 2.10.03, and they do not tell us how much any person's Moon, Venus, or Mars placement moved.

The manual gives 2.10.3 a different job. Under “Changes from version 2.10.02 to 2.10.03,” it lists a fix to swe_lun_eclipse_when(), which searches for lunar eclipses, and an improvement to the Moon's apparent-magnitude calculation for large phase angles when the Moon is close to the Sun. The upstream “2.10.03” release entry also describes those two categories, but its eclipse date span differs: the manual says 776–967 CE, while the release entry says 766–987 CE and reports 74 missed eclipses out of 506. The records agree on the kind of function fixed, not on the precise historical interval. That discrepancy should stay visible; it gives no reason to merge either eclipse detail with the separate 2.10.01 longitude correction.

Version numbers can sit close together while describing different calculation layers. A lunar ephemeris correction concerns position data under a stated calculation path; DE441 handling concerns use of a named JPL ephemeris; an eclipse search returns event results; and apparent magnitude concerns how bright the Moon appears. The words “Moon” or “lunar” do not make those changes interchangeable. Nor does a release list establish the cumulative degree difference between two builds for every date, body, or calculation mode used in a chart. The relevant 0.042-arcsecond value belongs to the earlier bug report, not to a matched comparison of 2.10.02 and 2.10.03.

So when someone says an update “moved the Moon,” ask which entry and which output they mean. First identify the library versions, then whether the comparison used the same ephemeris source and settings. Next request the two exact Moon longitudes for the same birth moment. Without that matched evidence, the 0.042-arcsecond figure cannot explain a changed sign or aspect label, and the 2.10.3 eclipse and magnitude fixes do not establish a changed synastry position. A difference near a sign boundary or aspect orb deserves checking, but the version history alone cannot show that one occurred.

Sources: Swiss Ephemeris Programmer's Manual: 2.10.02 to 2.10.03 changes; Releases · aloistr/swisseph

How can files change while a library version stays the same?

The library code and the ephemeris data it reads are separate inputs. Swiss Ephemeris can use original JPL data files, compressed Swiss Ephemeris files, or its built-in Moshier method. Astrodienst’s technical overview says the software selects among available sources according to installed files, while the programmer’s interface documents separate controls for the ephemeris path and JPL file selection. A version label identifies the code release; by itself, it does not tell you which data file was present or which calculation option the application requested. An update may replace a data file while leaving the library version untouched. Or an application may change its settings or the wrapper that passes options to the library. Those are possible causes to check, not facts to assume about a provider.

The page “Downloading Swiss Ephemeris Code and Data” lists compressed planet files, JPL files, and source code separately. Its instructions explain that the software searches a configured data path, which a program can set or an environment variable can influence. A file’s availability does not establish that a chart used it; the selected source depends on what the application can find and how it calls the library. Ask the provider which ephemeris source and files it used, and whether its calculation settings changed. If it cannot say, record the provenance as unknown. Don’t guess from a release number or from the existence of a newer file. The “swephprg programming interface” also separates library version reporting from current-file information, giving developers ways to inspect more than one part of the setup.

Documentation that a library can read a file format, or that a file is available to download, does not establish that every combination produces identical positions. Nor does it show that a particular application installed that file. The useful question is whether two chart outputs used the same source and settings. If they did not, request both positions under matched inputs before interpreting a difference. If the Moon, Venus, or Mars degree changed, compare exact values and check whether the difference crosses a sign boundary or affects an aspect under the same orb rule. If only the displayed label changed, check the application’s classification convention. The library version is one clue, not the whole provenance. A changed chart can justify asking about files and calculation mode even when the interface still says 2.10.3. But a newer data set alone is no evidence that either person’s placements moved. Keep source, file set, settings, and exact degrees together; then decide whether the synastry interpretation needs to change.

Sources: Swiss Ephemeris — for 8000 years and more; The JPL files download links; swephprg programming interface

What does the later DE441 transition add to the comparison?

Astrodienst says its Swiss planet and asteroid files have been based on JPL DE441 since May 2026. That is a change in the ephemeris data basis, separate from the Swiss Ephemeris 2.10.3 release notes about historical lunar-eclipse searching and the Moon’s apparent magnitude. A library version names code; an ephemeris designation names data. One label does not tell you that the other changed at the same time, or that every app adopted the newer files. The page “Swiss Ephemeris - for 8000 years and more” describes DE441 as the basis of Astrodienst’s Swiss files from that date. It also says the compressed Swiss data reproduce JPL data through Astrodienst’s compression process. This establishes Astrodienst’s data transition, not which files an app installed or uses for a given calculation. Astrodienst’s separate “The JPL files download links” page lists DE431 and DE441 as distinct files, showing that files have their own identity. A version number alone is incomplete provenance. What does the name DE441 tell you? JPL’s “The JPL Planetary and Lunar Ephemerides DE440 and DE441” explains that both solutions were fitted to the same data set. DE441 differs in its assumption about damping between the Moon’s liquid core and solid mantle: it assumes no damping, which avoids divergence when the solution is integrated backward over a long span. JPL describes the resulting tradeoff plainly. DE441 covers years -13,200 to +17,191, while DE440 covers 1550 to 2650; DE441 is less accurate than DE440 for the current century. The longer historical reach is useful, but does not make DE441 more accurate for every date. This comparison cannot tell a couple how many arcseconds a Moon, Venus, or Mars position changed. The JPL page compares ephemeris solutions; Astrodienst’s notice identifies its file transition. Neither reports matched calculations for a particular birth moment or a synastry sign or aspect change. Don’t translate “DE441” into “our placements moved.” Check the outputs. If a chart provider says it changed to DE441, ask which file set and calculation mode it used before and after, and request the exact degrees for the placements that differ. Compare the same birth moment and zodiac convention; then check whether a degree difference crosses a sign boundary or changes an aspect under the same orb rule. If the provider cannot identify a file or setting, mark that part unknown. The careful conclusion is modest: DE441 makes the data basis worth recording, but only matched calculations can show whether a particular synastry input changed. Until then, keep the supplied placements distinct from the story you build from them.

Sources: Swiss Ephemeris — for 8000 years and more; The JPL Planetary and Lunar Ephemerides DE440 and DE441; The JPL files download links

Which Moon, Venus, and Mars labels could change if positions differ?

The Moon, Venus, or Mars label changes only if the value used to assign that label crosses a relevant boundary. A sign label depends on the planet's zodiac longitude. An aspect label depends on the angular distance between two chart positions and the orb rule applied to that distance. So a different calculated degree could matter near a sign boundary or the edge of an aspect's allowed orb. A difference far from either boundary may leave both labels as they were. That conditional path matters because a changed number and a changed reading are not the same thing. First, two calculations would need to return different longitudes. Then the difference would need to cross a classification threshold. Only after that would the astrologer reconsider how much weight to give that placement or contact in the comparison. This separates a position value from the later classification. The Swiss Ephemeris Programmer's Interface documents coordinate calculations as a distinct operation. For a sign, picture the zodiac as twelve successive 30-degree divisions. A position close to the start or end of one division deserves closer checking if two outputs disagree. The Moon could be listed in one sign by one source and the neighboring sign by another if the matched calculation values fell on opposite sides of that boundary. The same rule applies to Venus and Mars. This example doesn't claim that 2.10.3 moved a body or that a particular chart sits near a boundary. Astrodienst describes different ephemeris sources and files, but gives no degree change for an individual chart. Aspect labels need a second person's position too. Compare the two longitudes, find their angular separation, and measure how far that separation sits from the exact angle assigned to an aspect. The orb is the permitted distance from that exact angle. Near the orb limit, a small difference in either position could move the contact inside or outside the rule. Far from the limit, it may leave the classification intact. Both reports must use the same aspect list and orb rule before their labels can be compared fairly. A sign-only list cannot settle these edge cases. Ask for the exact Moon, Venus, and Mars degrees in both outputs, along with the zodiac convention and aspect/orb settings. If the degrees match but the labels do not, inspect the classification rules. If the degrees differ, compare the birth moment, calculation mode, and ephemeris files before changing the interpretation. The Synastry Comparison Report interprets supplied placements and optional degrees; it doesn't calculate natal positions from birth details. Keep the reading open until inputs align.

Sources: swephprg programming interface; Swiss Ephemeris — for 8000 years and more

What should a reader record before comparing two outputs?

Compare chart outputs in a fixed order. Begin with the birth date, the recorded local birth time, and the time-zone conversion used to turn that civil time into the calculation time. A one-hour mismatch can change a chart input though both reports display the same date. If the source does not say how it handled a time zone or daylight-saving rule, record that as unknown. Don’t silently assume the two calculations began with the same moment.

Next, ask what calculation produced each set of positions. Record the application and library version, the ephemeris source or mode, the data files, and any disclosed coordinate or flags. The Swiss Ephemeris technical overview describes calculations using JPL files, compressed Swiss files, or its built-in Moshier method; the Swiss Ephemeris download page lists data files separately from the library. Together, they establish that code and data are distinct inputs. They do not reveal which files a particular chart provider used, so an undisclosed item stays unknown. Also note whether the charts use the same zodiac convention. Matching software labels alone does not establish matching calculation inputs.

Then compare the actual values, not just the labels. Ask for the exact ecliptic longitudes of both people’s Moon, Venus, and Mars, and zodiac convention. A sign name compresses a degree position into a 30-degree division, so it can hide how close a placement sits to a boundary. For aspects, record which angle the reader is checking and the orb rule used. The same two longitudes can receive different aspect labels under different orb settings. Recheck the sign and aspect classifications only after the underlying degrees and rules match.

Keep two questions separate: did the calculated number change, or did the interpretation change? If degrees match but the reports describe the contact differently, the difference may come from how each reader weighs the placements. If a degree or label differs, ask the provider whether it reflects birth-time handling, calculation mode, files, or settings. This turns a vague claim that an update ‘moved’ a placement into a checkable request: share the calculation inputs and exact degrees for both outputs.

Sources: swephprg programming interface; Swiss Ephemeris — for 8000 years and more; The JPL files download links

What is the supported verdict, and what should you do next?

The supported verdict is narrow: Swiss Ephemeris 2.10.3 documents a correction to lunar-eclipse searching and an improvement to the Moon’s apparent magnitude near the Sun. Those notes alone give no reason to revise ordinary Moon, Venus, or Mars signs or longitude-based synastry aspects. The Swiss Ephemeris Programmer’s Manual names these changes; Astrodienst’s technical overview shows that calculation files and modes are separate inputs. This guides the investigation, but doesn’t prove every output is identical. If two reports disagree, ask which library build, ephemeris source and files, calculation mode, birth-time conversion, and aspect rule were used. Request Moon, Venus, and Mars degrees for both people. Compare them under the same zodiac convention before revisiting sign labels or aspects. A difference near a sign boundary or orb edge deserves checking; a changed software label alone doesn’t establish a changed placement. Mark unavailable details unknown. Evidence that could change this verdict is a reproducible difference between matched calculations, or a disclosed data or settings change relevant to that boundary. The Synastry Comparison Report interprets supplied Moon, Venus, and Mars placements, optional degrees, and aspects using its six-degree orb. It doesn’t calculate natal charts from birth details, infer a missing birth time, or certify a relationship outcome. Compare the placements you have, note what remains unknown, then decide whether the evidence changes your reading.

Sources: Swiss Ephemeris Programmer's Manual: 2.10.02 to 2.10.03 changes; Swiss Ephemeris — for 8000 years and more

A little more clarity