TimeZoneInfo.StandardName empty when run under ubuntu-latest NET 8, while value present with NET 6

[lahma]

Description

I'm having some trouble wrapping my head around this. We have a test case in Jint that work under NET 6 and full framework, but now when trying to target NET 8 the TimeZoneInfo.StandardName is empty.

I created a simple assert that Pacific Standard Time has a name here:

https://github.com/lahma/timezone-repro/blob/main/UnitTest1.cs

Fails on NET 8 but not on NET 6, test project multi-targets both:

https://github.com/lahma/timezone-repro/actions/runs/6983316148/job/19004227812

I would understand that this could be any tzdata/ICU problem, but the same GitHub Actions runner is running both .NET 6 and 8 and thus I would expect that those databases are valid.

/cc @sebastienros

Reproduction Steps

https://github.com/lahma/timezone-repro

Expected behavior

Would print the correct time zone on both NET 6 and NET 8.

Actual behavior

NET 8 has empty StandardName

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

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

Issue Details

---

Description

I'm having some trouble wrapping my head around this. We have a test case in Jint that work under NET 6 and full framework, but now when trying to target NET 8 the StandardName is empty.

I created a simple assert that Pacific Standard Time has a name here:

https://github.com/lahma/timezone-repro/blob/main/UnitTest1.cs

Fails on NET 8 but not on NET 6, test project multi-targets both:

https://github.com/lahma/timezone-repro/actions/runs/6983316148/job/19004227812

I would understand that this could be any tzdata/ICU problem, but the same GitHub Actions runner is running both .NET 6 and 8 and thus I would expect that those databases are valid.

/cc @sebastienros

Reproduction Steps

https://github.com/lahma/timezone-repro

Expected behavior

Would print the correct time zone on both NET 6 and NET 8.

Actual behavior

NET 8 has empty StandardName

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	lahma
Assignees:	-
Labels:	area-System.DateTime
Milestone:	-

[Clockwork-Muse]

As remarked upon in the documentation, Linux uses ICU ids. Pacific Standard Time isn't an ICU id - the equivalent is America/Los_Angeles

I'm not sure why it worked on the .Net 6 version, if all other aspects were the same.
Note that there are methods to convert to/from ICU ids - you should likely switch to using ICU ids, and if you're running on Windows perform the conversion if required.

[lahma]

I do understand that there are different ids and some more preferable, what is puzzling here is why the behavior change and I did try to go trough all the breaking changes documentation for NET 8 and couldn't find anything related to this. Successfully resolving with an (non-preferred) id works but somehow it isn't identifiable with a name anymore.

EDIT: same codebase tries to support net462, net6.0 and net8.0

[lahma]

There was also fallbacks in place to support different naming schemes (net462, net6.0), it's a bit hard to get them working targeting both full and modern runtime.

https://github.com/sebastienros/jint/blob/473ca00c598cadaabc3259cabe271bc9e1d934f8/Jint.Tests/Runtime/EngineTests.cs#L30-L39

[Clockwork-Muse]

Sorry, I initially read this as "Doesn't find the timezone at all", but that's not the case.

Some slightly expanded testing reveals that the Daylight/Display name are also empty, but Id is the passed-in value.
Note that the UTC Offset is correct, so it's clearly finding it.

Given the announcing blog post, I'm not sure whether the display names/etc are actually guaranteed, as opposed to just getting the zone at all...

[lahma]

Thank you for creating the sample. I would say that the results for name are quite unpredictable at the moment by varying by target framework. I was able to work around the problem by changing the search order using ICU id first which will return the name, but it feels surprising still.

So there's a workaround but maybe it would be worth to update the breaking changes document if this behavior is deemed as such.

[Clockwork-Muse]

I would say that the results for name are quite unpredictable at the moment by varying by target framework

Names aren't guaranteed to be static even on the same target framework - the data solely comes from the OS, and can change for multiple reasons. This has always been the case, even on Windows.
You aren't even guaranteed a static list of ids either - Windows in particular used to limit the number of zones installed to some of the more common ones (in addition to trimming almost all historical data). Some trimmed down versions of Linux outright don't install the timezone database (common in server applications).

Don't rely on any specific data in tests - you have no control over whether the id exists, what name it has, or especially the offsets and any DST rules. If you want to test specific cases, the platform and framework-agnostic way to do that is to construct your own TimeZoneInfo instance and pass it in to the required methods (easier now that we have TimeProvider). TimeZone data is relatively volatile - it updates multiple times a year. You can validate that you get something back, but that's about it.

[tarekgh]

This looks a bug and not intentional.

[tarekgh]

This is a regression from the change #88368. In this change we have changed to get the TZ names in lazy way. When requesting the name, we check if the name is null and then initialize it. Unfortunately, during the initial creation of the TZI object we set the names to empty strings instead of null which causes the name never to get initialized.

runtime/src/libraries/System.Private.CoreLib/src/System/TimeZoneInfo.cs

Line 1015 in 882c60c

_standardDisplayName = standardDisplayName ?? string.Empty;

CC @mdh1418