Problem
The JUnit reporter (node --test --test-reporter=junit) emits <testsuite> elements without the timestamp attribute defined by the JUnit/Ant XML schema. timestamp records, in ISO 8601, when the suite started; Node never writes it.
Why it matters
<testsuite timestamp> is how JUnit-consuming tools (CI dashboards, test-report viewers) anchor each suite on a time axis — for example, to order suites coming back from parallel/sharded runs, and to build per-suite history and trends across runs. Without it, consumers fall back to file mtime or the overall job time, which is coarser and can be misleading.
Node is also an outlier among JUnit producers: pytest (--junitxml), jest-junit, mocha-junit-reporter, and Maven Surefire all emit timestamp on <testsuite>. Node's reporter already emits time and hostname on <testsuite> (and file on <testcase>), but not timestamp.
Current behavior
$ node --test --test-reporter=junit ...
<testsuite name="my suite" time="0.42" disabled="0" errors="0" tests="2" failures="0" skipped="0" hostname="...">
No timestamp attribute is present.
Proposed solution
In lib/internal/test_runner/reporter/junit.js, emit the suite start time as the timestamp attribute on each <testsuite>.
There is one open question — the value format:
- Full ISO 8601 with timezone (e.g.
2026-06-20T12:34:56.789Z). This is what Date.prototype.toISOString() produces directly, it is unambiguous about the instant, and it is the direction newer tooling (pytest 8.x, Maven Surefire 3.5.5+) is moving.
- Legacy no-timezone Ant form (e.g.
2026-06-20T12:34:56). This is the canonical de-facto format (Ant XMLJUnitResultFormatter; the strict windyroad JUnit XSD even pins it to \d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2} with no zone) and what jest-junit / mocha-junit-reporter currently emit, but it is ambiguous about the actual instant.
Problem
The JUnit reporter (
node --test --test-reporter=junit) emits<testsuite>elements without thetimestampattribute defined by the JUnit/Ant XML schema.timestamprecords, in ISO 8601, when the suite started; Node never writes it.Why it matters
<testsuite timestamp>is how JUnit-consuming tools (CI dashboards, test-report viewers) anchor each suite on a time axis — for example, to order suites coming back from parallel/sharded runs, and to build per-suite history and trends across runs. Without it, consumers fall back to file mtime or the overall job time, which is coarser and can be misleading.Node is also an outlier among JUnit producers: pytest (
--junitxml),jest-junit,mocha-junit-reporter, and Maven Surefire all emittimestampon<testsuite>. Node's reporter already emitstimeandhostnameon<testsuite>(andfileon<testcase>), but nottimestamp.Current behavior
No
timestampattribute is present.Proposed solution
In
lib/internal/test_runner/reporter/junit.js, emit the suite start time as thetimestampattribute on each<testsuite>.There is one open question — the value format:
2026-06-20T12:34:56.789Z). This is whatDate.prototype.toISOString()produces directly, it is unambiguous about the instant, and it is the direction newer tooling (pytest 8.x, Maven Surefire 3.5.5+) is moving.2026-06-20T12:34:56). This is the canonical de-facto format (AntXMLJUnitResultFormatter; the strict windyroad JUnit XSD even pins it to\d{4}-\d{2}-\d{2}T\d{2}:\d{2}:\d{2}with no zone) and whatjest-junit/mocha-junit-reportercurrently emit, but it is ambiguous about the actual instant.