runtime: TimeZoneInfo.ToSerializedString/FromSerializedString do not round trip on Unix

The following test passes on Windows but fails on Unix:

public static IEnumerable<object[]> SystemTimeZonesTestData()
{
    foreach (TimeZoneInfo tz in TimeZoneInfo.GetSystemTimeZones())
    {
        yield return new object[] { tz };
    }
}

[Theory]
[MemberData(nameof(SystemTimeZonesTestData))]
public static void ToSerializedString_FromSerializedString_RoundTrips(TimeZoneInfo timeZone)
{
    string serialized = timeZone.ToSerializedString();
    TimeZoneInfo deserializedTimeZone = TimeZoneInfo.FromSerializedString(serialized);
    Assert.Equal(timeZone, deserializedTimeZone);
    Assert.Equal(serialized, deserializedTimeZone.ToSerializedString());
}

I believe it’s due to how GetAdjustmentRules is implemented on Unix: https://github.com/dotnet/coreclr/blob/0a11492d52faa85c551761f8390be5de9d74e5ec/src/mscorlib/src/System/TimeZoneInfo.Unix.cs#L131-L153

vs. on Windows: https://github.com/dotnet/coreclr/blob/0a11492d52faa85c551761f8390be5de9d74e5ec/src/mscorlib/src/System/TimeZoneInfo.Win32.cs#L87

See dotnet/corefx#14795

Also, when you pass an AdjustmentRule[] array to TimeZoneInfo.CreateCustomTimeZone to create a custom instance of TimeZoneInfo, calling GetAdjustmentRules on Windows will always give you a cloned copy of the same adjustment rules, whereas on Unix it looks like it will modify the adjustment rules that are returned.

About this issue

  • Original URL
  • State: open
  • Created 7 years ago
  • Comments: 18 (10 by maintainers)

Most upvoted comments

There is still time for 3.1 but that window is closing quickly, we’re already in “Ask mode” where we are scrutinizing risk of all fixes going into 3.1. If we can come up with a low risk fix in the next week it has a chance at getting in.

We do not accept servicing requests for past releases through Github, please see https://dotnet.microsoft.com/platform/support/policy/dotnet-core, https://github.com/dotnet/core/blob/master/microsoft-support.md for details around backporting to past releases. The short answer is: if you need this for .NETCore 2.1, please open a support request, .NETCore 2.2 is no longer recieving hotfixes (only security fixes).

Sorry, do you mean it should be serialized in different way for linux and windows?

No. what I meant, if there is a way to detect the string is serialized on Linux and interpret the serialized data differently to get the original intended information. I don’t know yet if this is possible. I just wanted to say, if there is any reasonable workaround can be used here.