TimeZoneInfo.TryConvertWindowsIdToIanaId() difference compared to TZConvert.TryWindowsToIana() #53279
Description
Description
As part of trying out .NET 6 preview 4 on an existing .NET 5 application, I tried swapping out usage of the TimeZoneConverter NuGet package with TimeZoneInfo.TryConvertWindowsIdToIanaId as described in the blog post.
Upon doing this, some existing unit tests for the existing application failed due to different IANA time zones being returned. The three specific differences I found when using TimeZoneInfo.TryConvertWindowsIdToIanaId(string, string, out string) compared to TZConvert.TryWindowsToIana(string, string, out string) are:
"Romance Standard Time"and"es"returns"Europe/Paris"instead of"Europe/Madrid""Romance Standard Time"and"ie"returns"Europe/London"instead of"Europe/Dublin""Romance Standard Time"and"it"returns"Europe/Berlin"instead of"Europe/Rome"
This can be replicated with the unit test class below.
The blog post seems to imply that this usage would be a supported like-for-like replacement, but as it's behaving differently I've made the assumption this is a bug and not the intended behaviour.
Removes need to use TimeZoneConverter OSS library. The functionality is now built-in.
However if this is not a supported scenario for the new APIs, then it would just be the case that for my specific use case I would need to retain the use of the TimeZoneConverter package.
using System.Collections.Generic;
using TimeZoneConverter;
using Xunit;
namespace System
{
public static class TimeZoneTests
{
public static IEnumerable<object[]> TestCases()
{
yield return new object[] { "au", "Cen. Australia Standard Time", "Australia/Adelaide" };
yield return new object[] { "au", "AUS Central Standard Time", "Australia/Darwin" };
yield return new object[] { "au", "E. Australia Standard Time", "Australia/Brisbane" };
yield return new object[] { "au", "AUS Eastern Standard Time", "Australia/Sydney" };
yield return new object[] { "au", "Tasmania Standard Time", "Australia/Hobart" };
yield return new object[] { "es", "Romance Standard Time", "Europe/Madrid" };
yield return new object[] { "gb", "GMT Standard Time", "Europe/London" };
yield return new object[] { "ie", "GMT Standard Time", "Europe/Dublin" };
yield return new object[] { "it", "W. Europe Standard Time", "Europe/Rome" };
yield return new object[] { "nz", "New Zealand Standard Time", "Pacific/Auckland" };
}
[Theory]
[MemberData(nameof(TestCases))]
public static void TZConvert_TryWindowsToIana(string territoryCode, string windowsTimeZoneId, string expected)
{
// Act
bool result = TZConvert.TryWindowsToIana(windowsTimeZoneId, territoryCode, out string actual);
// Assert
Assert.True(result);
Assert.Equal(expected, actual);
}
[Theory]
[MemberData(nameof(TestCases))]
public static void TimeZoneInfo_TryConvertWindowsIdToIanaId(string territoryCode, string windowsTimeZoneId, string expected)
{
// Act
bool result = TimeZoneInfo.TryConvertWindowsIdToIanaId(windowsTimeZoneId, territoryCode, out string actual);
// Assert
Assert.True(result);
Assert.Equal(expected, actual);
}
}
}Configuration
.NET SDK 6.0.100-preview.4.21255.9 on Windows 10 (Version 2004 (OS Build 19041.985)).
Regression?
No, this functionality is new in .NET 6 preview 4, but it is behaving differently to TimeZoneConverter which the blog post implies it is a replacement for. If this is a use case which is supported as a replacement, then I would expect it to behave the same.