[GH-ISSUE #6835] [Bug] Environment clock parsing rejects valid ISO timestamps in years 0000–0099 #4178

New issue

Closed

opened 2026-10-31 00:47:27 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 00:47:27 +00:00

Owner

Originally created by @coygeek on GitHub (Oct 23, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/6835

Before submitting

I searched the open and closed issues for a related report.
I removed credentials, tokens, private paths, and sensitive target data.

Area

Evidence, artifacts, or reconstruction

Observed behavior

The environment clock reader returns undefined for valid four-digit ISO timestamps in years 0000 through 0099. Consequently respellClock leaves these timestamps unchanged instead of applying a recorded clock format, and environment comparison labels their format differences as ordinary value differences. A year-0100 control is recognized and respelled correctly.

Reproduction

From the source checkout with its locked dependencies installed, run this production-helper probe:

node --import tsx --input-type=module <<'JS'
import { readClock, respellClock } from './src/domain/analysisView/environmentStateWriteValues.ts';
const format = { kind: 'iso', separator: ' ', fraction: 3, zone: 'Z' };
for (const year of ['0000', '0001', '0099', '0100']) {
  const input = `${year}-01-01T00:00:00Z`;
  console.log(input, Number.isFinite(Date.parse(input)), readClock(input) !== undefined, respellClock(input, format));
}
JS

This was executed once over all four inputs. All are valid native dates; only the year-0100 control is recognized by REA. The same failure was observed through compareEnvironment using synthetic capture Evidence for a GET response with a created_at field. The CLI itself was not launched.

Expected behavior

Recognize valid four-digit ISO timestamps consistently, including year 0001 values used as sentinel timestamps, and apply the requested spelling. For example, respelling 0001-01-01T00:00:00Z with the format above should produce 0001-01-01 00:00:00.000Z. Existing malformed-calendar checks should continue to reject invalid dates. The helper's documented contract is an ISO-8601 date-time reader; no first-century exclusion is declared.

Impact and scope

Observed on the shared environment-state clock helper and environment comparison workflow. Early-year values cannot participate correctly in clock respelling or format classification. Later-year controls work. End-to-end CLI execution and release-package behavior were not tested; this is a source-checkout report.

REA version

Source revision 169512a35bb015ff209168fb8bc1c9b31a2c678b (main, package metadata 6.7.0).

Runtime and platform

Node.js v26.12.1; Linux x86_64.

Target and artifact context

Synthetic JSON response timestamps; no external application or target.

Interface

CLI

Earliest failure stage

Transport or result projection

Relevant output or evidence

Observed helper output, shown as input / native-date-valid / REA-recognized / respelled:

0000-01-01T00:00:00Z true false 0000-01-01T00:00:00Z
0001-01-01T00:00:00Z true false 0001-01-01T00:00:00Z
0099-01-01T00:00:00Z true false 0099-01-01T00:00:00Z
0100-01-01T00:00:00Z true true 0100-01-01 00:00:00.000Z

The shared reader constructs the date with Date.UTC(year, ...) and then compares its year with the input: reader source. JavaScript applies its 1900 adjustment to numeric years 0–99, so the round-trip check rejects these otherwise valid inputs. This cause is source-derived; the returned values above were executed observations.

Typed outcome or recovery expected

A recognized clock with the original year and source format, allowing the existing clock conversion and comparison paths to operate.

Additional context

compareEnvironment returned category value for first-century timestamps whose spellings differed, while a later-year control returned clock-format. No installed configuration was changed.

Originally created by @coygeek on GitHub (Oct 23, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/6835 ### Before submitting - [x] I searched the open and closed issues for a related report. - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area Evidence, artifacts, or reconstruction ### Observed behavior The environment clock reader returns `undefined` for valid four-digit ISO timestamps in years 0000 through 0099. Consequently `respellClock` leaves these timestamps unchanged instead of applying a recorded clock format, and environment comparison labels their format differences as ordinary value differences. A year-0100 control is recognized and respelled correctly. ### Reproduction From the source checkout with its locked dependencies installed, run this production-helper probe: ```sh node --import tsx --input-type=module <<'JS' import { readClock, respellClock } from './src/domain/analysisView/environmentStateWriteValues.ts'; const format = { kind: 'iso', separator: ' ', fraction: 3, zone: 'Z' }; for (const year of ['0000', '0001', '0099', '0100']) { const input = `${year}-01-01T00:00:00Z`; console.log(input, Number.isFinite(Date.parse(input)), readClock(input) !== undefined, respellClock(input, format)); } JS ``` This was executed once over all four inputs. All are valid native dates; only the year-0100 control is recognized by REA. The same failure was observed through `compareEnvironment` using synthetic capture Evidence for a GET response with a `created_at` field. The CLI itself was not launched. ### Expected behavior Recognize valid four-digit ISO timestamps consistently, including year 0001 values used as sentinel timestamps, and apply the requested spelling. For example, respelling `0001-01-01T00:00:00Z` with the format above should produce `0001-01-01 00:00:00.000Z`. Existing malformed-calendar checks should continue to reject invalid dates. The helper's documented contract is an ISO-8601 date-time reader; no first-century exclusion is declared. ### Impact and scope Observed on the shared environment-state clock helper and environment comparison workflow. Early-year values cannot participate correctly in clock respelling or format classification. Later-year controls work. End-to-end CLI execution and release-package behavior were not tested; this is a source-checkout report. ### REA version Source revision `169512a35bb015ff209168fb8bc1c9b31a2c678b` (`main`, package metadata 6.7.0). ### Runtime and platform Node.js v26.12.1; Linux x86_64. ### Target and artifact context Synthetic JSON response timestamps; no external application or target. ### Interface CLI ### Earliest failure stage Transport or result projection ### Relevant output or evidence Observed helper output, shown as input / native-date-valid / REA-recognized / respelled: ```text 0000-01-01T00:00:00Z true false 0000-01-01T00:00:00Z 0001-01-01T00:00:00Z true false 0001-01-01T00:00:00Z 0099-01-01T00:00:00Z true false 0099-01-01T00:00:00Z 0100-01-01T00:00:00Z true true 0100-01-01 00:00:00.000Z ``` The shared reader constructs the date with `Date.UTC(year, ...)` and then compares its year with the input: [reader source](https://github.com/morluto/rea/blob/169512a35bb015ff209168fb8bc1c9b31a2c678b/src/domain/analysisView/environmentStateWriteValues.ts#L48-L87). JavaScript applies its 1900 adjustment to numeric years 0–99, so the round-trip check rejects these otherwise valid inputs. This cause is source-derived; the returned values above were executed observations. ### Typed outcome or recovery expected A recognized clock with the original year and source format, allowing the existing clock conversion and comparison paths to operate. ### Additional context `compareEnvironment` returned category `value` for first-century timestamps whose spellings differed, while a later-year control returned `clock-format`. No installed configuration was changed.

bsakaguchi closed this issue

2026-10-31 00:47:28 +00:00

bsakaguchi referenced this issue

2026-10-31 01:11:57 +00:00

[PR #4178] [MERGED] fix(process): preserve unrelated trace comparison uncertainty #6112