Fix culture-dependent timestamp in HTML test report (#5868)#5872
Fix culture-dependent timestamp in HTML test report (#5868)#5872
Conversation
The HTML reporter rendered the report timestamp with `dd MMM yyyy, HH:mm:ss 'UTC'` and no `IFormatProvider`, so the localized month abbreviation leaked into the output (e.g. `08 5月 2026, 17:40:20 UTC` on Japanese systems). Switch to standard format strings, which are culture-invariant by spec: `R` (RFC1123) for English UI cultures, `u` (universal sortable) otherwise. Defensive `ToUniversalTime()` so the helper is robust if a future caller passes a non-UTC value.
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review: Fix culture-dependent timestamp in HTML test report (#5868)
The bug fix is valid — the original "dd MMM yyyy, HH:mm:ss 'UTC'" format without an IFormatProvider is genuinely broken on non-English systems, and this PR correctly diagnoses the root cause.
Main concern: unnecessary branching introduces a new consistency problem
The fix introduces two different output formats depending on the running machine's UI culture:
return CultureInfo.CurrentUICulture.TwoLetterISOLanguageName == "en"
? utc.ToString("R") // "Sun, 10 May 2026 17:40:20 GMT"
: utc.ToString("u"); // "2026-05-10 17:40:20Z"This means two people running the same test suite and sharing the HTML report artifact will see timestamps in different formats. That hurts:
- Reproducibility: CI on an English agent produces a different timestamp format than CI on a Japanese agent.
- Downstream consumers: anything scraping or parsing the HTML report now needs to handle two formats.
- Snapshot tests: if TUnit ever snapshots report output, this will cause flakiness.
Simpler correct fix
The simplest correct approach is to pass CultureInfo.InvariantCulture to the original format string, which preserves the existing human-readable style and changes nothing except making it culture-safe:
Timestamp = DateTimeOffset.UtcNow.ToString("dd MMM yyyy, HH:mm:ss 'UTC'", CultureInfo.InvariantCulture),If a format change is desired for other reasons, a single invariant format is still better than branching:
private static string FormatTimestamp(DateTimeOffset value) =>
value.ToUniversalTime().ToString("u", CultureInfo.InvariantCulture); // "2026-05-10 17:40:20Z"Why this is better: one format, deterministic output, no dependency on the runner machine's locale. Even though DateTimeOffset.ToString("R") is invariant by spec, being explicit with CultureInfo.InvariantCulture removes any ambiguity and makes intent clear to future readers.
Minor note
R format emits GMT where the old code said UTC — the PR acknowledges this as cosmetic, which is fair. Just worth flagging that it is a visible change in the English output.
Summary
The diagnosis and intent are correct. The suggested improvement is to drop the CurrentUICulture branch entirely and use a single invariant format string, which fixes the localization bug without introducing format inconsistency across environments.
Up to standards ✅🟢 Issues
|
Drop CurrentUICulture branch per review feedback. Single deterministic format avoids cross-machine output divergence.
There was a problem hiding this comment.
Follow-up Review
The second commit (8cb0658) addresses the concern raised in the previous review — the CurrentUICulture branch has been dropped entirely.
What changed
The fix is now:
Timestamp = DateTimeOffset.UtcNow.ToString("dd MMM yyyy, HH:mm:ss 'UTC'", CultureInfo.InvariantCulture),This is the minimal, correct approach: pass CultureInfo.InvariantCulture to the existing format string. Output is deterministic regardless of the runner machine's locale, the human-readable style is preserved, and there's no branching on CurrentUICulture.
Minor note: PR description drift
The PR description still references the two-format branching approach (R for English, u for non-English) and the different output examples, but the code no longer does that. The description could be updated to reflect the final implementation, though this doesn't affect correctness.
Overall
The fix is clean, minimal, and directly solves the root cause. No concerns. ✅
1 participant
Summary
HtmlReporterwas rendering the report timestamp withdd MMM yyyy, HH:mm:ss 'UTC'and noIFormatProvider, so the localized month abbreviation leaked into the output — e.g.08 5月 2026, 17:40:20 UTCon Japanese systems.CultureInfoargument required):R(RFC1123) for English UI cultures,u(universal sortable ISO) otherwise. DefensiveToUniversalTime()so the helper is robust if a future caller passes a non-UTC value.Output examples:
Sun, 10 May 2026 17:40:20 GMT2026-05-10 17:40:20ZNote:
Remits the literalGMT(functionally identical to UTC); the previous output saidUTC. Minor cosmetic change for the English path.Test plan
dotnet build TUnit.EnginecleanCultureInfo.CurrentUICultureset toja-JP, confirm timestamp reads2026-...Z(not5月)en-US, confirm timestamp reads... GMT