A constant whose value is a date and whose absolute uncertainty is a time duration cannot be recalled in its value±uncertainty (range) form — it raises an error.
Example. T₀☽ (Moon time of perigee passage) evaluates to a date and carries a ±5 min uncertainty. Recalling it with its uncertainty should read e.g.
14 6 2026, 11:18:50 ± 00:05:00
but it currently errors.
Cause (from the source). constant::range() builds the ± form via range::make(ID_drange, value, uncertainty) — a decimal range (drange). It runs to_decimal on the uncertainty and tries to align it to the value's unit. When the value is a date and the uncertainty is a time duration (e.g. 300_s), this drange construction can't reconcile the two types, so it fails. (With a zero, same-type uncertainty like 0_date, no range is formed, hence no error — which is why the previous fixed T₀ constants didn't trip it.)
Request. Support a range whose centre is a date and whose half-width is a time duration, rendered as DD MM YYYY, HH:MM:SS ± HH:MM:SS. This could be a dedicated date-range kind, or an extension of the range machinery to accept a date centre with a duration half-width — the underlying date±duration arithmetic already exists (days_after / days_before).
Why it matters. Time-of-passage constants (lunar perigee, planetary perihelia) are naturally a date ± a few minutes; without this, their uncertainty can't be displayed even though it's meaningful and stored.
A constant whose value is a date and whose absolute uncertainty is a time duration cannot be recalled in its value±uncertainty (range) form — it raises an error.
Example.
T₀☽(Moon time of perigee passage) evaluates to a date and carries a ±5 min uncertainty. Recalling it with its uncertainty should read e.g.14 6 2026, 11:18:50 ± 00:05:00but it currently errors.
Cause (from the source).
constant::range()builds the ± form viarange::make(ID_drange, value, uncertainty)— a decimal range (drange). It runsto_decimalon the uncertainty and tries to align it to the value's unit. When the value is a date and the uncertainty is a time duration (e.g.300_s), thisdrangeconstruction can't reconcile the two types, so it fails. (With a zero, same-type uncertainty like0_date, no range is formed, hence no error — which is why the previous fixedT₀constants didn't trip it.)Request. Support a range whose centre is a date and whose half-width is a time duration, rendered as
DD MM YYYY, HH:MM:SS ± HH:MM:SS. This could be a dedicated date-range kind, or an extension of the range machinery to accept a date centre with a duration half-width — the underlying date±duration arithmetic already exists (days_after / days_before).Why it matters. Time-of-passage constants (lunar perigee, planetary perihelia) are naturally a date ± a few minutes; without this, their uncertainty can't be displayed even though it's meaningful and stored.