[WASM] new trimmer feature System.TimeZoneInfo.Invariant

[pavelsavara]

Motivation: when TryGetLocalTzFile is included it brings dependency to System.IO.File and its dependencies.

• new trimmer feature System.TimeZoneInfo.Invariant triggered by existing <InvariantTimezone>true</InvariantTimezone>
  • breaking change: it will prevent loading TZ info files from FS
• new System.TimeZoneInfo.Invariant getter also driven by DOTNET_SYSTEM_TIMEZONE_INVARIANT env variable
• cleanup ILLink.Substitutions.LegacyJsInterop.xml

Together with dotnet/sdk#45792

<InvariantTimezone>true</InvariantTimezone> is pre-existing feature.

[dotnet-policy-service]

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

[tarekgh]

Will it be acceptable to have DateTime.Now report wrong time when the invariant mode is enabled?

[pavelsavara]

Will it be acceptable to have DateTime.Now report wrong time when the invariant mode is enabled?

It will report UTC. Also this behavior already existed before this PR, here I'm just removing the ability to load TZ data from file system, when InvariantTimezone is true.

[tarekgh]

It will report UTC. Also this behavior already existed before this PR, here I'm just removing the ability to load TZ data from file system, when InvariantTimezone is true.

Thanks. I am not sure my question is answered :-) I am not questioning the PR more than questioning behavior. I guess users haven't run into this yet to report it. Returning UTC time when having TZ settings different than UTC is questionable. Maybe it is acceptable to the browser (especially servers) but wanted to know how we validated this assumption.
Maybe the explicit opt-in switch introduced here is better as users will explicitly enable and understand the consequences.

[pavelsavara]

Returning UTC time when having TZ settings different than UTC is questionable.

This is not how it works. You would not be able to change to non-UTC timezone. Let me show you:

given code

Console.WriteLine($"TimeZoneInfo.Local is {TimeZoneInfo.Local}");
Console.WriteLine($"DateTime.UtcNow is {DateTime.UtcNow}");
Console.WriteLine($"DateTime.Now is {DateTime.Now}");
var start = DateTime.UtcNow;
var timezonesCount = TimeZoneInfo.GetSystemTimeZones().Count;
await Delay(100);
var end = DateTime.UtcNow;
Console.WriteLine($"Found {timezonesCount} timezones in the TZ database in {end - start}");

TimeZoneInfo utc = TimeZoneInfo.FindSystemTimeZoneById("UTC");
Console.WriteLine($"{utc.DisplayName} BaseUtcOffset is {utc.BaseUtcOffset}");

try
{
    TimeZoneInfo tst = TimeZoneInfo.FindSystemTimeZoneById("Asia/Tokyo");
    Console.WriteLine($"{tst.DisplayName} BaseUtcOffset is {tst.BaseUtcOffset}");
}
catch (TimeZoneNotFoundException tznfe)
{
    Console.WriteLine($"Could not find Asia/Tokyo: {tznfe.Message}");
}

At 12:19 in Prague, you will get following output

TimeZoneInfo.Local is (UTC) UTC
DateTime.UtcNow is 1/9/2025 11:19:52 AM
DateTime.Now is 1/9/2025 11:19:52 AM
Found 0 timezones in the TZ database in 00:00:00.1200000
(UTC) UTC BaseUtcOffset is 00:00:00
Could not find Asia/Tokyo: The time zone ID 'Asia/Tokyo' was not found on the local computer.

[pavelsavara]

The <InvariantTimezone>true</InvariantTimezone> feature is opt-in and it means: "I don't care for timezones, please make the application as small as possible".

On the browser "operating system" we don't have TZ database pre-installed and so we are bundling it with each application. It's 300KB of download and some CPU time before the runtime can start. That's a lot for a web app, especially if your business logic is not about dates/times/calendars.

Before this PR the <InvariantTimezone>true</InvariantTimezone> would just stop shipping the data. But you would be able to ship your own and store it into emscripten virtual file system yourself. There are probably nobody in the world that knew this was possible.

I feel quite safe to make this change for the browser target.

@steveisok is this how it works for iOS too ?

Can I assume people are not shipping custom TZDIR there at the same time when they set <InvariantTimezone>true</InvariantTimezone> ?

[steveisok]

@steveisok is this how it works for iOS too ?

We don't ship anything custom on iOS or Android as we rely on whatever they do.

[sbomer]

What's the expected precedence if someone sets <InvariantTimezone>true</InvariantTimezone> and DOTNET_SYSTEM_TIMEZONE_INVARIANT=false?

[eerhardt]

AppContextConfigHelper.GetBooleanConfig (which Invariant Globalization uses) checks the env var first, and then the runtimeconfig:

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

Lines 13 to 29 in 058fe35

	internal static bool GetBooleanConfig(string switchName, string envVariable, bool defaultValue = false)
	{
	string? str = Environment.GetEnvironmentVariable(envVariable);
	if (str != null)
	{
	if (str == "1" || bool.IsTrueStringIgnoreCase(str))
	{
	return true;
	}
	if (str == "0" || bool.IsFalseStringIgnoreCase(str))
	{
	return false;
	}
	}
	return GetBooleanConfig(switchName, defaultValue);
	}

[pavelsavara]

<InvariantTimezone>true</InvariantTimezone> will trigger linker to substitute the call to GetBooleanConfig to constant true.

[sbomer]

So with trimming, <InvariantTimezone>true</InvariantTimezone> wins, and without trimming, DOTNET_SYSTEM_TIMEZONE_INVARIANT=false wins. Is that the behavior we want? Typically we try to avoid behavior changes introduced by trimming.

[MichalStrehovsky]

This is not necessary, we only put here whatever switches are enabled by default in an empty console app.

[MichalStrehovsky]

Same here, not necessary.

[MichalStrehovsky]

Should this switch be respected on other platforms too? I know it will not lead to real size savings, but consistency is quite important. Feature switches are problematic in general because they change behavior of code that was unit tested or used elsewhere without the feature switch being set: there might be subtle bugs introduced by the feature switch that bypassed quality gates. Making the feature switch effect as visible as possible helps to at least somewhat mitigate that.