Erratum — draft-fossil-artifact-format-00 §4.6.4

Document	draft-fossil-artifact-format-00
Section	4.6.4 — Timestamps (accepted parser grammar)
Type	Editorial (clarification — the field constraints are correct; their placement scopes them to the wrong form)
Status	Proposed — operator decision pending
Reported	2026-10-08
Submitter	Dan Mestas
Found via	libfossil conformance triage (artifact.4.6.4.invalid-month) + independent verification against the Fossil reference implementation

1. Summary

§4.6.4 lists five token forms a parser accepts. The paragraph giving the field constraints (digit counts and ranges for year, month, day, hour, minute, second and fraction) is printed inside item 5, the bare-decimal Julian day number. Item 5 has none of those fields. Read literally, the constraints apply to nothing, and items 1 to 3 have no range checks at all. The constraints belong to the forms that carry those fields. This erratum moves the paragraph out of the list.

2. Location

§4.6.4 (Timestamps), list item 5 (~lines 1013-1019):

   5.  A bare decimal number, treated as a Julian day number when its
       value r satisfies 0 < r < 5373484.5.  Field constraints, with
       exact digit counts: the year is exactly 4 digits, the month
       exactly 2 digits in 01-12, the day exactly 2 digits in 01-31 with
       no calendar-aware check (2024-02-31 is accepted), the hour 2
       digits in 00-24, the minute and second 2 digits each in 00-59,
       and the fraction one or more digits.

3. The reading hazard

The fields the constraints name exist only in items 1 to 3: year, month and day in the date-time and date-only forms, hour, minute, second and fraction in the date-time and time-only forms. Item 4 is a literal and item 5 is a single number. Nesting the paragraph under item 5 gives a reader two wrong choices: apply the ranges to the Julian-day form, where they cannot apply, or treat items 1 to 3 as unconstrained and accept 2026-13-02T03:04:05.

The reference implementation applies the ranges to the date and time fields. Verified with fossil test-parse-manifest (fossil 2.28):

• D 2026-13-02T03:04:05 is rejected ("cannot parse date on D-card").
• D 2026-01-02 (date only) is accepted.

4. Impact

No wire-byte change and no change to which tokens are valid. The hazard is implementer-facing: an implementation that follows the list structure can skip the month and day range checks. libfossil's parser does, and it accepts the month-13 token above, which the reference implementation rejects.

5. Correction (editorial move)

End item 5 after its Julian-day sentence, and move the field constraints into their own paragraph after the list, naming the forms they govern:

    5.  A bare decimal number, treated as a Julian day number when its
-       value r satisfies 0 < r < 5373484.5.  Field constraints, with
-       exact digit counts: the year is exactly 4 digits, the month
-       exactly 2 digits in 01-12, the day exactly 2 digits in 01-31 with
-       no calendar-aware check (2024-02-31 is accepted), the hour 2
-       digits in 00-24, the minute and second 2 digits each in 00-59,
-       and the fraction one or more digits.
+       value r satisfies 0 < r < 5373484.5.
+
+   In forms 1 through 3, each field present has exact digit counts and
+   ranges: the year is exactly 4 digits, the month exactly 2 digits in
+   01-12, the day exactly 2 digits in 01-31 with no calendar-aware
+   check (2024-02-31 is accepted), the hour 2 digits in 00-24, the
+   minute and second 2 digits each in 00-59, and the fraction one or
+   more digits.

6. Rationale

• Scopes the constraints to the forms that have the fields. "In forms 1 through 3, each field present" says where they apply, so the Julian-day form keeps only its own 0 < r < 5373484.5 bound.
• Leaves the constraint text unchanged. Only the placement and the lead-in change; every digit count and range is the same.
• Matches the reference implementation, which rejects an out-of-range month in a date-time token and accepts the date-only form.

7. Application and verification

• The libfossil conformance case artifact.4.6.4.invalid-month already assumes the corrected reading: it expects D 2026-13-02T03:04:05 to be rejected.
• Verified against the reference implementation (fossil 2.28, test-parse-manifest): 2026-13-02, 2026-01-32, 2026-01-32T03:04:05, 2026-01-02T25:04:05 and 2026-01-02T03:60:05 are rejected ("cannot parse date on D-card"); 2026-01-02, 2026-01-02T03:04:05 and the Julian-day number 2461000.5 are accepted.

---

Prepared against draft-fossil-artifact-format-00. The section is substantively faithful; the correction is editorial. Surfaced when libfossil conformance triage found its parser following the list structure literally. The RFC remains the oracle; the reference implementation is used only to confirm the correct observable behavior, per the interop-verification policy.