Unrecognized time zone id Customized Time Zone

[jakoss]

Describe the bug
I'm trying to parse attached ics file, but i have an error: Unrecognized time zone id Customized Time Zone.

I'm pretty sure that the entries with this Customized Time Zone are entries created by accepting invitation from Google Meet from outlook application.

To Reproduce
Try to parse attached file

var calendarString = File.ReadAllText(@"<your path>\calendar.ics");
var calendar = Calendar.Load(calendarString);
var occurrences = calendar.GetOccurrences(DateTime.UtcNow, DateTime.UtcNow).ToList(); // crashes here

1. iCalendar Data
   Attached in file calendar.zip

Expected behavior
I know there is no "proper" solution to handle this, but for now the only thing i can do is to do enumeration manually and handle the exception there which is not ideal. I'd love to have some solution, maybe just skip such entries but return everything else?

Environment (please complete the following information):

• OS: Windows 11
• .NET version: .NET 8
• ical.net version: 5.0.0-pre.41

[axunonb]

@minichma Seems to be broken starting with #732

[minichma]

Seems to be broken starting with #732

Yes, it was an explicit decision to stop falling back to the local timezone if the TZ is unknown. From the PR description:

• Stop falling back to the local TZ if the specified TZ is unknown. Its more than likely that in most cases the fallback is not what is expected/desired by the user.

I'm pretty sure that also in this case the fallback to the local tz is not what is desired. Actually if I understand @jakoss correctly, they just want it to work 'some way'.

Possible solutions and workarounds:

• The right solution would actually be to consider the TZ definition for the unknown TZ within the ics file, but that's not something we have in place today.
• Keep falling back to local tz - probably not a good idea
• Fall back to some other random TZ like UTC or assume floating time - probably also not a good idea, as it simply isn't correct
• Make the fallback configurable via the new EvaluationOptions - better
• Make the whole TZ resolution configurable via EvaluationOptions - much better, but not too straight forward for now
• Introduce some configuration that allows skipping values that can't be resolved - should be doable
• Manually override TZ resolution in user code by means as introduced in Make the time zone resolver plugable #732

Overriding TZ resolution in user code is probably the simplest and most straight-forward way for now and could be done as follows:

TimeZoneResolvers.TimeZoneResolver = tzId =>
    TimeZoneResolvers.Default(tzId)
    // fall back to UTC if the TZ tzId is unknown
    ?? TimeZoneResolvers.Default("UTC");

// should work even if unknown TZIDs appear
var occurrences = calendar.GetOccurrences(DateTime.UtcNow, DateTime.UtcNow).ToList();

Using a global static configuration is far from perfect but for the given case it should work.

[minichma]

It seems that indeed Microsoft 366 is unsung customized timezones, so we'll probably have to provide a built in solution for such cats.

[axunonb]

I'm pretty sure that also in this case the fallback to the local tz is not what is desired

Agree

It seems that indeed Microsoft 365 is unsung customized timezones, so we'll probably have to provide a built in solution

Agree, not only because of MS, but because it's part of RFC5545, section 3.6.5. Not sure about the best way to implement. A custom timezone resolver as part of the Calendar?

[minichma]

The right way would probably be to implement Noda DateTimeZone based on Ical.Net VTimeZone and use it for evaluation rather than Noda's built in TZ. Question would be whether to use it only where no built in TZ is available or generally where possible. Implementing it should not be too hard, except for GetZoneInterval, which requires iterating the TZ recurrences backwards to find the start of the interval, which isn't implemented today and is not too trivial.

A short term workaround would be to fall back to floating time if the TZ is unknown, which wouldn't be correct but certainly better than local time.

[jakoss]

For me specifying my own fallback timezone would be just enough (i checked and all of those entries are in my default TZ). Right now i did the most primitive workaround imaginable, which is string.Replace on the ical directly where i replace this custom TZ to CET

[axunonb]

specifying my own fallback timezone

Yes, sure. Still I'd prefer ical.net can deal with custom timezones out of the box.

@minichma I had a closer look and hope I got what you have in mind. So I could start working on that.
It's indeed quite straightforward. We could just add one last step to DefaultTimeZoneResolver.GetZone() with sth. like

providerId = CustomDateTimeZoneProvider.Instance.Ids.FirstOrDefault(tzId.Contains);
if (providerId != null)
{
    return CustomDateTimeZoneProvider.Instance.GetZoneOrNull(tzId) ?? throw new ArgumentException(exMsg);
}

right?

Question would be whether to use it only where no built in TZ is available or generally where possible.

You mean whether we put the CustomDateTimeZoneProvider evaluation to the top or to the end of DefaultTimeZoneResolver.GetZone() method?

[axunonb]

@minichma This) is WIP for custom timezones.

Currently, a new VTimeZoneProvider gets plugged into DateTimeZone GetZone(string tzId):`

providerId = VTimeZoneProvider.Instance.Ids.FirstOrDefault(tzId.Contains);
if (providerId != null)
{
    return VTimeZoneProvider.Instance.GetZoneOrNull(tzId) ?? throw new ArgumentException(exMsg);
}

This works, but the VTimeZoneProvider is static and not bound to e.g. a Calendar, which requires a workaround like below.
There must be a better way... Any hint appreciated.

public void Occurrences_WithCustomTimeZone()
{
    var ics = IcsFiles.VTimeZone1;

    var calendar = Calendar.Load(ics);
    VTimeZoneInitializer.ClearTimeZones();
    VTimeZoneInitializer.AddTimeZones(calendar);

    var occ = calendar.GetOccurrences().ToList();

    Assert.That(occ, Has.Count.EqualTo(1));
}

[minichma]

Hm, that's a quite fundamental one, probably rather for a v6 than v5 or it would require quite a fundamental overhaul of v5. Making the global TZ resolver pluggable was kind of a viable workaround for v5, but now that its associated with the individual Calendar, that's not an option anymore. Here are my thoughts on a viable solution:

• Separate the model from the evaluation part
• Make sure, no TZ operations are involved on the model side. This includes removing any AsUtc, CalDateTime.Add, .Subtract, .Compare, .ToTimeZone, CalendarEvent.EffectiveDuration, .GetOccurrences(), ...
• When transitioning to the evaluation tier, pass the Calendar, i.e. do something like that

var evaluationContext = new EvaluationContext(calendar);
var eventEvaluator = new EventEvaluator(evaluationContext);

or

var calendarEvaluator = new CalendarEvaluator(calendar);
var occurrences = calendarEvaluator.GetOccurrences();

• The EvaluationContext holds a IDateTimeResolver property. If constructed from a Calendar as above, it is initialized from the Calendar's VTimeZone instances.
• The context is passed to any Evaluator like RecurrencePatternEvaluator, etc. and the IDateTimeProvider is used for any TZ operations.
• As suggested in Version 6 #739 things would get somewhat simpler if we'd reuse NodaTime types on the evaluation part of things, i.e. use ZonedDateTime rather than CalDateTime as the former already has a reference to the Zone and arithmetic operations would therefore be straight forward and not require passing in the context.

[minichma]

@jakoss

For me specifying my own fallback timezone would be just enough

Then the workaround as drafted above should work just fine for you:

TimeZoneResolvers.TimeZoneResolver = tzId =>
    TimeZoneResolvers.Default(tzId)
    // fall back to CET if the TZ tzId is unknown
    ?? TimeZoneResolvers.Default("CET");

[jakoss]

Can confirm that works for me