Repository navigation
TimeZoneInfoTests.NoBackwardTimeZones tests are failing on Android #117731
Description
Build Information
Build: https://dev.azure.com/dnceng-public/cbb18261-c48f-4abb-8651-8cdcb5474649/_build/results?buildId=1096605
Build error leg or test failing: System.Tests.TimeZoneInfoTests.NoBackwardTimeZones
Pull request: #117630
07-16 11:57:57.303 28828 28920 I DOTNET : 1) [FAIL] System.Tests.TimeZoneInfoTests.NoBackwardTimeZones Test name: System.Tests.TimeZoneInfoTests.NoBackwardTimeZones
07-16 11:57:57.303 28828 28920 I DOTNET : Assembly: [System.Runtime.Tests, Version=10.0.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51]
07-16 11:57:57.303 28828 28920 I DOTNET : Exception messages: Assert.Equal() Failure: Values differ
07-16 11:57:57.303 28828 28920 I DOTNET : Expected: 596
07-16 11:57:57.303 28828 28920 I DOTNET : Actual: 450 Exception stack traces: at System.Tests.TimeZoneInfoTests.NoBackwardTimeZones()
07-16 11:57:57.303 28828 28920 I DOTNET : at System.Reflection.MethodBaseInvoker.InterpretedInvoke_Method(Object obj, IntPtr* args)
07-16 11:57:57.303 28828 28920 I DOTNET : at System.Reflection.MethodBaseInvoker.InvokeWithNoArgs(Object obj, BindingFlags invokeAttr)
Error Message
Fill the error message using step by step known issues guidance.
{
"ErrorMessage": "Exception stack traces: at System.Tests.TimeZoneInfoTests.NoBackwardTimeZones()",
"ErrorPattern": "",
"BuildRetry": false,
"ExcludeConsoleLog": false
}Known issue validation
Build: 🔎 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1096605
Error message validated: [Exception stack traces: at System.Tests.TimeZoneInfoTests.NoBackwardTimeZones()]
Result validation: ✅ Known issue matched with the provided build.
Validation performed at: 7/16/2025 7:00:02 PM UTC
Report
| Build | Definition | Test | Pull Request |
|---|---|---|---|
| 1096605 | dotnet/runtime | System.Runtime.Tests.WorkItemExecution | #117630 |
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 1 | 1 | 1 |
Report
Summary
| 24-Hour Hit Count | 7-Day Hit Count | 1-Month Count |
|---|---|---|
| 0 | 0 | 0 |
Activity
dotnet-policy-service commentedon Jul 16, 2025
Tagging subscribers to 'arch-android': @vitek-karas, @simonrozsival, @steveisok, @akoeplinger
See info in area-owners.md if you want to be subscribed.
dotnet-policy-service commentedon Jul 16, 2025
Tagging subscribers to this area: @dotnet/area-system-datetime
See info in area-owners.md if you want to be subscribed.
steveisok commentedon Jul 16, 2025
@matouskozak if this flakes, it might be something weird with a specific device or devices.
tarekgh commentedon Jul 16, 2025
This looks that OS's are getting new TZ data. Look at #117422 which is reported on macOS 26 Preview 3.
matouskozak commentedon Jul 17, 2025
Indeed, I looked into the history, and it is only failing on
DNCENGWIN-140device since 2025-07-10 https://dev.azure.com/dnceng-public/public/_build/results?buildId=1091157&view=results (only on PRs).danmoseley commentedon Mar 22, 2026
Note
This comment was generated with the help of AI/Copilot.
Took a look at this to understand the current state. A few observations:
Root cause: On Android,
GetTimeZoneIds()filters backward zones viatzlookup.xml(FilterBackwardIDsinTimeZoneInfo.Unix.Android.cs). Iftzlookup.xmlis missing or incomplete on the device,FilterBackwardIDsreturnsnulland all ~596 IDs are treated as non-backward — resulting in duplicate display names (596 total vs 450 unique).PR #121095 didn't help Android: That fix returns a filtered dictionary from
PopulateAllSystemTimeZones, but it iteratesGetTimeZoneIds(), which on Android still returns all IDs whentzlookup.xmlis absent. The fix only helped Linux/macOS (wherezone.tabis the authoritative source).The single-device claim is unverifiable: The comment from @matouskozak mentions this only fails on
DNCENGWIN-140, but both referenced builds (1096605,1091157) have been purged from AzDO. The issue body edit history (which may have had additional build IDs) isn't accessible via GitHub's API either. So we can't cross-reference agent names across multiple builds to confirm it's truly device-isolated.Questions:
DNCENGWIN-140still in the pool? Has anyone checked whethertzlookup.xmlexists on its connected Android device?tzlookup.xmlcase more robustly (e.g., deduplicating by display name as a fallback)?[ActiveIssue]) to see if the situation has changed?