Julian Date Converter mechanism

Model scope

The specification is not verifiable as written because it gives only the algorithm name, not the formulas or calendar/time-scale conventions. The vectors assume the standard proleptic-Gregorian Fliegel & Van Flandern integer-date calculation, JD = JDN - 0.5 + time_fraction, and MJD = JD - 2400000.5. The empty honest_label is a concern: the instrument should explicitly state Gregorian-calendar scope, UTC/leap-second handling, JD noon origin, MJD offset, supported year range, and numeric precision.

• The spec names the Fliegel & Van Flandern algorithm but does not provide the actual forward formula, inverse formula, or branch conditions, so every claimed conversion cannot be fully verified from the specification alone.
• The calendar system is unspecified: the Gregorian-only, proleptic Gregorian, Julian, and historical Gregorian-reform interpretations produce different results for some dates.
• UTC handling is unspecified. UTC contains leap seconds, while ordinary JD arithmetic assumes a uniform 86400-second day; the behavior for timestamps such as 23:59:60 is not defined.
• The inverse JD-to-calendar-date algorithm and its handling of Gregorian/Julian calendar selection are not specified.
• Input validity constraints are missing, including valid month/day ranges, leap-year validation, supported year range, year-zero convention, and whether fractional seconds are accepted.

Units and conventions

• The test vectors assume the proleptic Gregorian calendar for all dates.
• Time-of-day is represented as a fraction of a 86400-second day; leap seconds are ignored.
• Julian Date is assumed to begin at noon UTC, so JD at midnight has a .5 fractional part.
• Modified Julian Date is assumed to be MJD = JD - 2400000.5.
• Times are assumed to be UTC labels treated as if they were uniformly spaced arithmetic timestamps.
• Expected numeric values are rounded to the shown decimal precision; a production implementation should define an output precision policy.

Inspectable vector

One of 4 source-bound review vectors:

{
  "inputs": {
    "calendar_date": "2000-01-01",
    "time": "12:00:00",
    "timezone": "UTC"
  },
  "expected_outputs": {
    "JD": 2451545,
    "MJD": 51544.5,
    "calendar_date": "2000-01-01T12:00:00Z"
  },
  "working": "Use a=floor((14-M)/12)=floor(13/12)=1; y=Y+4800-a=2000+4800-1=6799; m=M+12a-3=1+12-3=10. JDN=D+floor((153m+2)/5)+365y+floor(y/4)-floor(y/100)+floor(y/400)-32045 = 1+floor(1532/5)+365(6799)+floor(6799/4)-floor(6799/100)+floor(6799/400)-32045 = 1+306+2481635+1699-67+16-32045 = 2451545. Fraction of day = (12*3600)/86400 = 0.5. JD = JDN - 0.5 + 0.5 = 2451545.0. MJD = 2451545.0 - 2400000.5 = 51544.5."
}

Failure boundary

• Division by zero is not expected in the standard arithmetic, but malformed or non-finite numeric inputs can propagate NaN or infinity and must be rejected.
• Invalid calendar dates, including 2023-02-29 and month 13, must be rejected rather than normalized silently.
• Leap-second input such as 2016-12-31T23:59:60Z has undefined behavior unless explicitly rejected or modeled.
• Floating-point precision can lose sub-second accuracy for large JD values when using ordinary JavaScript Number arithmetic.
• Negative years, year zero, and dates before the Gregorian calendar reform require an explicit convention.
• A JD numeric input must be distinguished from a calendar-date input; ambiguous numeric strings or local-time strings can cause incorrect conversions.
• The inverse conversion must define behavior at the noon boundary, where JD integer values correspond to 12:00:00 rather than 00:00:00.

Other records

Sources and evidence

These pointers bind the page to evidence. They do not grant authority or collapse verification into deployment.

• VERIFIED_LEDGER.json
• evidence-tranche4/tranche4-results.json