Skip to content

Make JUnit testsuite timestamp timezone-aware - #252

Open
ItIsUday wants to merge 1 commit into
spekt:masterfrom
ItIsUday:junit-timezone-aware-timestamp
Open

ItIsUday wants to merge 1 commit into
spekt:masterfrom
ItIsUday:junit-timezone-aware-timestamp

Conversation

@ItIsUday

@ItIsUday ItIsUday commented Nov 1, 2026 •

Copy link
Copy Markdown

Problem

The JUnit <testsuite timestamp> is serialized with DateTime.ToString("s"), which drops the offset: timestamp="2024-01-15T10:30:00". Since StartTime is DateTime.UtcNow, that string is UTC with nothing marking it as UTC, so a consumer in another timezone reads it as local time — ambiguous.

Change

Format with an explicit offset, yyyy-MM-ddTHH:mm:sszzz (InvariantCulture):

timestamp="2024-01-15T10:30:00+00:00"

Same digits as before, plus the offset.

  • zzz appends the offset rather than "o" (which would also inject 7-digit fractional seconds).
  • InvariantCulture guarantees the ISO : separator regardless of runner locale.
  • The bundled test/assets/JUnit.xsd types timestamp as xs:string, so it stays schema-valid and the existing XSD acceptance tests pass.

Tests

Added TestSuiteTimestampShouldBeTimezoneAware. dotnet test for JUnit.Xml.TestLogger.UnitTests passes (15/15).

🤖 Generated with Claude Code

The `<testsuite timestamp>` attribute was serialized with `DateTime.ToString("s")`,
which emits the date-time with no UTC offset. Because `StartTime` is captured as
`DateTime.UtcNow`, consumers received a UTC wall-clock value that looks like local
time, so a run cannot be pinned to an unambiguous instant and elapsed wall-clock
time is wrong whenever the consumer's timezone differs from the producer's.

Format the timestamp with an explicit offset (`yyyy-MM-ddTHH:mm:sszzz`,
InvariantCulture). With the existing `DateTime.UtcNow` start time this now emits
`...+00:00`, an unambiguous instant that is independent of the runner's timezone,
while keeping the same wall-clock digits as before. The JUnit XSD in this repo
types `timestamp` as `xs:string`, so the offset remains schema-valid.

Add a unit test asserting the serialized timestamp carries the offset.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant