You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I believe the recent time zones feature addition will not work with Blazor WASM as it currently is implemented. I had done some work with time zones earlier this year with a WASM project and found that only the IANA zones are provided with the Blazor WASM runtime - from .NET 6. I understand this has to do with the way Blazor Interop passes dates to/from the JS. I don't think will require a big change to the way blazor_calendar has time zones implemented. Really the only change needs to be in ToTuiTimeZone in TUICalendarTimeZoneOption.
Rather than returning null when parsing the TimeZoneId, we could check to see which format is provided (IANA or Windows) and then either use TimeZoneInfo.TryConvertWindowsIdToIanaId() for Windows or just the provided TimeZoneInfo object if it's already an IANA TimeZoneId. Something along these lines
// try to parse the id as a Windows Time Zone Id
string timezoneName = string.Empty;
if (!TimeZoneInfo.TryConvertWindowsIdToIanaId(timeZoneInfo.Id, out timezoneName))
{
// Not Windows or not found, use IANA
timezoneName = timeZoneInfo.DisplayName;
}
There is an open issue requesting support for both Windows and IANA TimeZoneIds (dotnet/runtime#64778) so maybe this won't be an issue for long.
@paulsterling Thanks for taking the time to comment on this!
How about restricting time
entry to only IANA values? What would we be losing by restricting windows ids? (I suppose some existing data based on windows time zone could be affected?) I like your current idea to mitigate null return value.
I like that Nuget package, but they suggest updating frequently, (which is probably ok, but would rather a more stable option).
I concur with prescribing use of the IANA time zone Ids. That way we'll be (more) platform agnostic and it should work with all Blazor runtimes across various platforms. Anyhow, Windows time zones can be strangely named IMHO but the IANA time zones follow a more predictable pattern.
I believe the recent time zones feature addition will not work with Blazor WASM as it currently is implemented. I had done some work with time zones earlier this year with a WASM project and found that only the IANA zones are provided with the Blazor WASM runtime - from .NET 6. I understand this has to do with the way Blazor Interop passes dates to/from the JS. I don't think will require a big change to the way blazor_calendar has time zones implemented. Really the only change needs to be in
ToTuiTimeZone
inTUICalendarTimeZoneOption
.Rather than returning null when parsing the TimeZoneId, we could check to see which format is provided (IANA or Windows) and then either use
TimeZoneInfo.TryConvertWindowsIdToIanaId()
for Windows or just the provided TimeZoneInfo object if it's already an IANA TimeZoneId. Something along these linesThere is an open issue requesting support for both Windows and IANA TimeZoneIds (dotnet/runtime#64778) so maybe this won't be an issue for long.
Possibly, it might make sense to use something like the time zone converter library that has already solved the various time zone platform variations (https://devblogs.microsoft.com/dotnet/cross-platform-time-zones-with-net-core/).
The text was updated successfully, but these errors were encountered: