I use NodaTime to do time zone conversions in ical.net, because it performs much better than the previous implementation which tried to use the VTIMEZONE
element to handle time changes and time zone conversions.
Under the hood, this method is pretty important for performance: it drops the test suite runtime from about 6 seconds to around 2.5.
public static DateTimeZone GetZone(string tzId)
{
// IANA lookup attempt
zone = DateTimeZoneProviders.Bcl.GetZoneOrNull(tzId);
if (zone != null)
{
return zone;
}
// Serialization lookup attempt
// Some other tricks to find a reasonable time zone, etc.
}
The .NET Core implementation of NodaTime does not have Bcl
as a DateTimeZoneProvider
. (It still has Tzdb
and Serialization
.) I poked around in the NodaTime source a bit, but I wasn't sure what the replacement was meant to be, if any.
What should we be using for BCL time zone lookups in the .NET Core port of NodaTime?
What should we be using for BCL time zone lookups in the .NET Core port of NodaTime?
Unfortunately, there isn't good TimeZoneInfo
support in the PCL profile that Noda Time 1.x supports - even FindSystemTimeZoneById()
and the Id
property aren't provided. As noted in comments, there's encouraging signs that they might be in .NET Core itself - I'll need to look.
You could use TzdbDateTimeZoneSource.WindowsMapping
to get the nearest equivalent IANA/TZDB time zone... but ideally, it would be better if you could use IANA/TZDB time zone IDs throughout your code. (Those will be more portable for other platforms, too.)
Even if FindSystemTimeZoneById
is supported on .NET Core, it won't provide the Windows time zones if you're on Linux - it uses the zoneinfo
files. So if you need Windows time zone portability, I think WindowsMapping
really is the best option.
Update: Having just looked again, we definitely can't support TimeZoneInfo
in .NET Core, as it doesn't expose adjustment rules :(
See more on this question at Stackoverflow