Inconsistent validation behavior in TimeZoneInfo.ConvertTime between Windows/Linux

[solid1353]

Description

The provided example throws an exception on Linux in docker container, however it does not on Windows.

Reproduction Steps

var result = TimeZoneInfo.ConvertTime(
    new DateTime(1984, 04, 29, 02, 00, 00, DateTimeKind.Unspecified),
    TimeZoneInfo.FindSystemTimeZoneById("US/Eastern"),
    TimeZoneInfo.Local
);

Expected behavior

It should either throw in both cases or not throw at all.

Configuration

Windows:

.NET 8 Windows 11 Pro 22621.3737

Linux:

Default docker image/environment

[dotnet-policy-service[bot]]

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

[Clockwork-Muse]

Ah, welcome to your first experience with one of the most insidious root causes in programming.

Configuration drift.

C# pulls the timezone data from the host operating system, and even two instances of the same operating system aren't guaranteed to have the same timezone data (although they usually do). At the moment, Linux and Windows definitely don't - Linux (most often) uses what's known as ICU for the data, and Windows has its own set of timezone data. One particular casualty of this is that Windows doesn't always have historical data - my guess would be that that time is being incorrectly reported as not a DST transition point in Windows (but is in Linux, because it actually happened then).

Anyways, what I'm getting at is that there isn't really a way to force conformance here without a lot of infrastructure work/management on your part. If you're writing an application that will be run by a third party, you're out of luck. Depending on what you're actually trying to accomplish, switching to NodaTime may be a better option.

Linux: Default docker image/environment

This isn't actually sufficient data to judge the Linux setup, we'd need at least the full container name+tag. Note too that almost all container images forgo ICU data (since they're supposed to be run on a server in UTC, and thus likely don't need the localization), and so would need ICU version (say via uconv -V).

[vadimkantorov]

Maybe a way forward could be an optional explicit knob to use ICU data even on Windows? In some contexts, users can afford to ship/update ICU data/dbs themselves... For debugging these issues, maybe worth exposing in public API some property of tzinfo data source/origin (which could include any OS/ICU info and versions)

[Clockwork-Muse]

It's not going to change the fundamental problem of configuration drift, it's a non-trivial problem to solve at scale. If the client application hasn't yet pulled the latest ICU data, you still end up with this error. And it's a concurrent modification situation too, so can happen at any point.

You could add the necessary APIs to detect and respond to this situation, but if you want to do this today you need to use NodaTime - the BCL just flat out doesn't have the APIs (or the data) to detect or properly respond to this (you'd need a lot of custom code).

As a side note, I'm expecting Microsoft to eventually switch the timezone source to ICU as well, but that's going to take a while. And even then won't stop the configuration drift anyways (especially since their ICU library lags a bit from most Linux distros).

[tarekgh]

US/Eastern is considered a legacy time zone name. Recently some Linux distros started to exclude these legacy zones from the TZ data. Users have to opt-in to install such data. You may look at https://github.com/dotnet/runtime/issues/103864 for more info.

@solid1353 please provide more info about the Linux distro installed in container and check if the US/Eastern data installed on the system.

[dotnet-policy-service[bot]]

This issue has been marked needs-author-action and may be missing some important information.

[dotnet-policy-service[bot]]

This issue will now be closed since it had been marked no-recent-activity but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.