Critical Bug: Antikythera's Position Command Ignores Date

by Alex Johnson 58 views

Hey everyone! We've stumbled upon a pretty critical bug that's affecting how the Antikythera engine handles time. It looks like the position command is completely ignoring the --date parameter. This is a big deal because it means we can't accurately replay historical events or observe phenomena like Mars retrograde in 2027. Let's dive into what's happening and how we plan to fix it.

The Problem: Frozen in Time

What we're seeing is that when we try to get the position of Mars using the antikythera position mars command with different dates, the output is exactly the same. We tested it with January 1st, February 1st, and March 1st, 2027, and for each, we got the same longitude, velocity, and coordinates. This is not what we expect at all! Mars's position and velocity should change significantly over these months, especially during a retrograde period. Instead, it's like looking at a frozen snapshot. This bug severely impacts our ability to perform historical replays and makes it impossible to study celestial events accurately.

The Evidence: Identical Outputs

Here's what we observed:

antikythera position mars --date 2027-01-01T00:00:00Z
antikythera position mars --date 2027-02-01T00:00:00Z
antikythera position mars --date 2027-03-01T00:00:00Z

All of these commands returned identical results, something like: longitude 125.937, velocity 0.071, RA 8.575. As you can imagine, Mars's longitude and velocity should vary quite a bit over a three-month span, particularly when it appears to be going retrograde. Seeing them stay frozen indicates a fundamental issue with how the --date parameter is being processed.

Our Investigation Plan: Pinpointing the Glitch

To get to the bottom of this, we've outlined a clear investigation plan. Our goal is to trace the --date parameter from the command line all the way through the engine to ensure it's being used correctly in calculations.

1. Verify Against NASA JPL HORIZONS

Our first step is to confirm what the correct positions and velocities for Mars should be during that period. We'll be using the NASA JPL HORIZONS system, a highly reliable source for ephemeris data. We'll configure it to provide Mars's ecliptic longitude, latitude, and range for January, February, March, and April of 2027, with a one-month step. This will give us a benchmark to compare our engine's output against. We expect Mars's longitude to decrease from January to March as it appears to move backward (retrograde) and then start increasing again in April. If our engine shows the same longitude for all these dates, it's a clear sign that the date parameter is indeed being ignored.

  • JPL HORIZONS web interface: https://ssd.jpl.nasa.gov/horizons/app.html
  • Configuration: Target Body: Mars, Observer Location: Geocentric, Time Span: 2027-Jan-01 to 2027-Apr-01 (step 1 month), Table Settings: ecliptic longitude (apparent, J2000), ecliptic latitude, observer range.
  • Expected Qualitative Behavior: Mars longitude around 126° in Jan, decreasing to ~120° in Feb, ~116° in Mar, and then increasing to ~118° in Apr, with velocity changing direction.

2. Find position Command Implementation

Next, we need to look at the actual code responsible for the position command. We'll be examining the file cli/commands/position.js to understand:

  • How the --date option is defined using the Commander library.
  • How this date value is parsed and then passed down to the core engine.
  • Whether there's any logic that might be falling back to the current date (new Date()) unintentionally.

3. Check Date Propagation into the Engine

Within cli/commands/position.js, we'll specifically check if the parsed date from options.date is actually being used when calling the engine's position function. For example, we're looking for a line similar to const data = await engine.getPosition(body, options.date);. We need to confirm:

  • Is options.date actually set when the --date flag is used?
  • Is there any code that ignores options.date and always uses new Date()?
  • Could the code be accidentally using a context variable like this.context.lastDate instead of the provided date?

4. Inspect Engine Implementation

After verifying the CLI part, we'll dive into the core engine.js file, specifically looking at the getPosition function (or similar functions responsible for state calculations). We'll use `grep -A 20