Error parsing VTIMEZONES from tzurl.org about ical.net HOT 11 CLOSED

The simplified versions for Outlook, e.g. http://tzurl.org/zoneinfo-outlook/Europe/Berlin.ics are working.

from ical.net.

In the future, please post a code snippet that shows how the error occurred instead of just a stack trace.

I assume you're doing something like:

const string berlin = "http://tzurl.org/zoneinfo/Europe/Berlin.ics";
var calendar = Calendar.LoadFromStream(new StringReader(berlin));

This isn't valid. You will have to download the contents of that URL, and then pass the ics contents as a string. The wiki has some examples of how to download a calendar, and then parsing the ics string.

ical.net will never support downloading resources from URLs. You will have to do that from within your application. The reasons for that are at the wiki section I linked above.

from ical.net.

nope downloaded via httpclient or webclient and passed the string. problem is the utc offset with seconds I believe. Can post the code when I have access to the pc later.

from ical.net.

Yeah, behind the scenes, it's using the Parse() method from either DateTime or DateTimeOffset, which doesn't support seconds.

Historically, dday.ical's original implementation used regex's to parse the offset, but it didn't work in some normal use cases (like if you prefixed a positive offset with a + which is Microsoft's way of displaying offsets!), so I threw away that part of the code, and replaced it with the built-in parser. There was no need for dday to re-invent the wheel.

from ical.net.

true a lot of redundant code in dday.ical :) still need me to find the code snippet or can you reproduce it?

from ical.net.

I can reproduce it, but I'm not going to fix it. It's a .NET library. It seems reasonable to use .NET conventions when they match the behavior of the BCL.

from ical.net.

But since a lot of clients use that timezone definitions (Davdroid for example) the library shouldn't crash when loading a valid ics file or?

from ical.net.

My time isn't unlimited. :) I'm not going to re-implement offset parsing to catch some corner case that could reasonably be caught by the client. There are no time zones that have resolutions smaller than 15 minute intervals.

The quick and dirty alternative it to see if there is more than one : at the end of the string, and truncate everything from the second : on if there is. You can do that if you'd like, if you like. I merge other people's PRs all the time.

from ical.net.

Ok will look into it in more detail, relevant code is in UTCOffsetSerializer.cs, right?

from ical.net.

actually according to the rfc 5545

3.3.14. UTC Offset

Value Name: UTC-OFFSET

Purpose: This value type is used to identify properties that contain
an offset from UTC to local time.

Format Definition: This value type is defined by the following
notation:

   utc-offset = time-numzone

   time-numzone = ("+" / "-") time-hour time-minute [time-second]

there are no : in it and therefore nothing to truncate

from ical.net.

Fix published in nuget version 2.2.32:
https://www.nuget.org/packages/Ical.Net

from ical.net.