Follow-up from guardian's review of #49 (WARN W1). Not reachable for any current tenant; filed so the next one that hits it finds this instead of a mystery.
The gap
lib/Charts/barColumnSnap.ts maps a bar's x to the timeline instant it contains, [columnStart, columnStart + span). That requires a bar's x to be at or before its own instants.
lib/Table/TableColumn.ts valuesAsDates tries ddmmyyyy → mmddyyyy → yyyyQQ → dateConstructor. Guardian confirmed by execution (in a non-UTC shell, so the result proves UTC rather than coincidence) that an ISO date-only column like 2025-01-26 reaches dateConstructor → Date.parse → UTC midnight, which satisfies the precondition. Every current consumer is ISO date-only.
But a CSV using dd-mm-yyyy / dd/mm/yyyy wins at ddmmyyyy (TableColumn.ts:302), which returns new Date(y, m-1, d) — local midnight:
| viewer TZ |
26-01-2025 parses to |
effect |
| UTC+1 |
2025-01-25T23:00:00Z |
safe — x lands before its instants |
| UTC-5 |
2025-01-26T05:00:00Z |
after a 02:31Z pass |
In the UTC-5 case that pass is contained by the previous day's column. Both directions of the snap agree on that wrong column, so nothing returns undefined and neither caller falls back — the click and the marker are self-consistently wrong by one period.
Why it is not urgent
- Not a regression: the nearest-match rule this replaced was wrong 25% of the time on the al-Shaheen archive regardless of timezone.
- Unreachable today — no tenant ships a
dd-mm-yyyy chart column.
- Already documented honestly in the module's "Basis note", including that the failure is silent rather than a fallback.
Fix when it matters
Normalise the comparison basis rather than assuming one: either have TableColumn expose the frame it parsed in, or make the callers derive the column start from the instant's own calendar day in the same frame the bars were parsed in. Do not paper over it by widening the span — that would swallow the neighbouring column's instants.
Related: #49, #50.
Follow-up from guardian's review of #49 (WARN W1). Not reachable for any current tenant; filed so the next one that hits it finds this instead of a mystery.
The gap
lib/Charts/barColumnSnap.tsmaps a bar's x to the timeline instant it contains,[columnStart, columnStart + span). That requires a bar's x to be at or before its own instants.lib/Table/TableColumn.tsvaluesAsDatestriesddmmyyyy→mmddyyyy→yyyyQQ→dateConstructor. Guardian confirmed by execution (in a non-UTC shell, so the result proves UTC rather than coincidence) that an ISO date-only column like2025-01-26reachesdateConstructor→Date.parse→ UTC midnight, which satisfies the precondition. Every current consumer is ISO date-only.But a CSV using
dd-mm-yyyy/dd/mm/yyyywins atddmmyyyy(TableColumn.ts:302), which returnsnew Date(y, m-1, d)— local midnight:26-01-2025parses to2025-01-25T23:00:00Z2025-01-26T05:00:00ZIn the UTC-5 case that pass is contained by the previous day's column. Both directions of the snap agree on that wrong column, so nothing returns
undefinedand neither caller falls back — the click and the marker are self-consistently wrong by one period.Why it is not urgent
dd-mm-yyyychart column.Fix when it matters
Normalise the comparison basis rather than assuming one: either have
TableColumnexpose the frame it parsed in, or make the callers derive the column start from the instant's own calendar day in the same frame the bars were parsed in. Do not paper over it by widening the span — that would swallow the neighbouring column's instants.Related: #49, #50.