Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Oct 23, 2025

Improves the System.Tests.TimeZoneInfoTests.NoBackwardTimeZones test to provide better diagnostics when duplicate timezone display names are detected.

Problem

The test was reported as failing on macOS 26 Preview 3 with:

Assert.Equal() Failure: Values differ
Expected: 419
Actual:   418

The test continues to fail on macOS 26.0.1 locally with duplicate timezone display names for "(UTC-05:00) Eastern Time (New York)" and "(UTC) Coordinated Universal Time".

Solution

Enhanced the test to provide detailed diagnostic information when duplicate display names are found:

  • Changed from HashSet<String> to Dictionary<String, List<String>> to track which timezone IDs map to each display name
  • Added duplicate detection logic that identifies all display names shared by multiple timezones
  • When duplicates are found, the test now fails with a descriptive message showing the exact display name and all timezone IDs that share it, e.g.: "Found 2 duplicate display name(s): '(UTC-05:00) Eastern Time (New York)' -> [America/New_York, US/Eastern], '(UTC) Coordinated Universal Time' -> [UTC, Etc/UTC]"

This provides much better diagnostics for debugging timezone data issues across different platforms while maintaining the test's original purpose of verifying unique display names. The test will now fail on macOS with helpful diagnostic information instead of being skipped.

Fixes #117422

Original prompt

This section details on the original issue you should resolve

<issue_title>NoBackwardTimeZones fails on macOS 26 Preview 3</issue_title>
<issue_description>System.Tests.TimeZoneInfoTests.NoBackwardTimeZones fails on macOS 26 preview 3

Assert.Equal() Failure: Values differ
Expected: 419
Actual:   418
  Stack Trace:
  /Users/vcsjones/Projects/runtime/src/libraries/System.Runtime/tests/System.Runtime.Tests/System/TimeZoneInfoTests.cs(2749,0): at System.Tests.TimeZoneInfoTests.NoBackwardTimeZones()
```</issue_description>

## Comments on the Issue (you are @copilot in this section)

<comments>
</comments>

Fixes #117422


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

Copilot AI changed the title [WIP] Fix NoBackwardTimeZones test failure on macOS 26 Skip NoBackwardTimeZones test on macOS due to duplicate timezone display names Oct 23, 2025
Copilot AI requested a review from stephentoub October 23, 2025 19:14
Copilot finished work on behalf of stephentoub October 23, 2025 19:14
@dotnet-policy-service
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-datetime
See info in area-owners.md if you want to be subscribed.

@stephentoub stephentoub marked this pull request as ready for review October 23, 2025 21:25
@Copilot Copilot AI review requested due to automatic review settings October 23, 2025 21:25
Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR addresses a test failure on macOS 26 Preview 3 where the NoBackwardTimeZones test fails due to duplicate timezone display names. The test expects all system timezones to have unique display names, but macOS 26 Preview 3 has 419 timezones with only 418 unique display names.

  • Added [ActiveIssue] attribute to skip the failing test on macOS platforms
  • References the existing issue #64111 that documents this behavior on Linux

@stephentoub stephentoub requested a review from tarekgh October 23, 2025 21:25
[ConditionalFact]
[ActiveIssue("https://github.com/dotnet/runtime/issues/64111", TestPlatforms.Linux)]
[ActiveIssue("https://github.com/dotnet/runtime/issues/117731", TestPlatforms.Android)]
[ActiveIssue("https://github.com/dotnet/runtime/issues/64111", TestPlatforms.OSX)]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this still a problem on macOS 26 as reported in the bug?

This test is not failing on macOS 26 outer loop extra platform runs: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1183077&view=ms.vss-test-web.build-test-results-tab&runId=32734848&paneView=debug

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure. I'm unable to check locally. The issue was opened recently, though.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cc: @vcsjones

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still fails for me locally on macOS 26.0.1. The duplicate timezones are ["(UTC-05:00) Eastern Time (New York)", "(UTC) Coordinated Universal Time"].

It's failing differently from me in the original issue I reported, too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right - I've removed the OSX ActiveIssue attribute. The improved test now provides better diagnostics if the issue resurfaces. Commit: 52fa883

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think [ActiveIssue("https://github.com/dotnet/runtime/issues/64111", TestPlatforms.Linux)] is skipping the MacOS run. I'll try to run locally to see if this is the case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, ActivityIssue isn’t related to this. It seems there’s an underlying issue in the product that needs further investigation. When running the full TZ test suite, the test passes, but when running only the NoBackwardTimeZones method, it fails. This likely means other tests are updating the cache in a way that affects GetSystemTimeZones, causing the test to pass when run together. However, when NoBackwardTimeZones runs alone, it creates the cache for the first time, which exposes the issue. I’ll look into this further when I have some time, but for now, we should assume the test can fail on macOS 26.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should both Linux and macOS be disable against the same issue - is it likely that Linux and macOS failures have the same root cause?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Most likely yes, the TZ handling on MacOS is the same as Linux.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkotas I have opened the PR #121095 to fix the issue on MacOS. I removed the ActiveIssue for Linux too to see if the CI will fail with that.

[ActiveIssue("https://github.com/dotnet/runtime/issues/64111", TestPlatforms.OSX)]
public static void NoBackwardTimeZones()
{
if (OperatingSystem.IsAndroid() && !OperatingSystem.IsAndroidVersionAtLeast(26))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@copilot Could you please update the test to show the duplicate timezones so that we get more details about the failure next time?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please update the test to show the duplicate timezones so that we get more details about the failure next time?

@jkotas, and presumably remove the ActiveIssue?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jkotas, and presumably remove the ActiveIssue?

@copilot yes

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updated the test to show duplicate timezones. When duplicates are found, the test now outputs: "Found N duplicate display name(s): 'DisplayName' -> [TimeZoneId1, TimeZoneId2]" for each duplicate. Commit: 52fa883

Copilot AI changed the title Skip NoBackwardTimeZones test on macOS due to duplicate timezone display names Improve NoBackwardTimeZones test diagnostics for duplicate timezone display names Oct 23, 2025
Copilot AI requested a review from jkotas October 23, 2025 22:19
Copilot finished work on behalf of jkotas October 23, 2025 22:19
Copilot finished work on behalf of vcsjones October 23, 2025 22:38
Copilot AI requested a review from vcsjones October 23, 2025 22:38
tarekgh added a commit to tarekgh/runtime that referenced this pull request Oct 27, 2025
@tarekgh
Copy link
Member

tarekgh commented Oct 27, 2025

Closing this in the favor of #121095

@tarekgh tarekgh closed this Oct 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NoBackwardTimeZones fails on macOS 26 Preview 3

5 participants