Fix culture-dependent timestamp in HTML test report (#5868)

[thomhurst]

Summary

• Fixes [Feature]: Culture-dependent DateTime formatting in test reports #5868. HtmlReporter was rendering 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.
• Switches to standard format strings (culture-invariant by .NET spec, no CultureInfo argument required): R (RFC1123) for English UI cultures, u (universal sortable ISO) otherwise. Defensive ToUniversalTime() so the helper is robust if a future caller passes a non-UTC value.

Output examples:

• English UI: Sun, 10 May 2026 17:40:20 GMT
• Any non-English UI: 2026-05-10 17:40:20Z

Note: R emits the literal GMT (functionally identical to UTC); the previous output said UTC. Minor cosmetic change for the English path.

Test plan

• dotnet build TUnit.Engine clean
• Manual smoke: run a small project against the HTML reporter with CultureInfo.CurrentUICulture set to ja-JP, confirm timestamp reads 2026-...Z (not 5月)
• Manual smoke: same with en-US, confirm timestamp reads ... GMT

[claude]

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.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[claude]

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. ✅