rianjs/ical.net

ical.NET - an open source iCal library for .NET

iCal.NET is an iCalendar (RFC 5545) class library for .NET aimed at providing RFC 5545 compliance, while providing full compatibility with popular calendaring applications and libraries.

Getting iCal.NET

iCal.NET is available as a nuget package.

Migrating from dday.ical to ical.net

There's a guide just for you: Migrating from dday.ical

Examples

The wiki contains several pages of examples of common ical.net usage scenarios.

• Simple event with a recurrence
• Deserializing an ics file
• Working with attachments
• Working with recurring elements
• Concurrency scenarios and PLINQ
• Migrating from dday.ical

Versioning

ical.net uses semantic versioning. In a nutshell:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards-compatible manner, and
3. PATCH version when you make backwards-compatible bug fixes.

Contributing

• Submit a bug report or issue
• Contribute code by submitting a pull request
• Ask a question

Support

ical.net is a something I do in my spare time around my family, day job, friends, and other hobbies. That means support is "when I get to it". I recognize that sometimes this isn't good enough, especially if you have a production issue. To that end, I offer paid support and bugfixes. A few basic rules before you contact me:

• Changes made to the ical.net library are open source.
• You do not own the changes I make to the library.
• Congruence with my vision for the future for ical.net is required. That means I won't do things like add Exchange interop, or take dependencies on third-party libraries that benefit only your use case.
• New versions of the library that result from changes made will be published on nuget for others to consume.

Please email me if paid support is something you require, and we can work out the details via email.

Creative Commons

iCal.NET logo adapted from Love Calendar By Sergey Demushkin, RU

ical.net's Issues

Better Nuget Logo

This will look better on Nuget.org.

Attachment added when start date is on/after a specific date (not supported calendar message.ics)

I have managed to get a Calendar invite setup and working as expected. However, when I reach a specific date for the Start date and after for an event, I get an email with the following file attached: "not supported calendar message.ics"

I am sending this using a multipart/alternative email. Adding a text/calendar alternative view with the relevant ICS content.

It seems to work as expected up until a specific start date and then after that start date, this is when it seems to get the email attachment included.

The code for this is as follows:

using (Calendar calendar = new Calendar())
{
    // DateTime eventDate = new DateTime(2016, 10, 30).ToUniversalTime(); // This seems to work fine
    DateTime eventDate = new DateTime(2016, 10, 31).ToUniversalTime(); // Using this date (and after) results in Attachment - "not supported calendar message.ics"
    calendar.Method = "REQUEST";

    // Create the event
    Event eventTraineeReview = new Event()
    {
        Uid = Guid.NewGuid().ToString("N"),
        Summary = "Test Event Invite",
        Description = "Test Event Description",
        Location = "Test Location",
        Start = new CalDateTime(eventDate),
        End = new CalDateTime(eventDate.AddHours(1)),
        Sequence = 0,
        Created = new CalDateTime(DateTime.Now),
        LastModified = new CalDateTime(DateTime.Now)
    };

    // Set the organizer of the event
    eventTraineeReview.Organizer = new Organizer()
    {
        CommonName = "Test Organizer",
        Value = new Uri("MAILTO:[email protected]")
    };

    // Create an alarm for the event
    Alarm alarmTraineeReview = new Alarm()
    {
        Action = AlarmAction.Display,
        Description = "REMINDER",
        Trigger = new Trigger()
        {
            Duration = TimeSpan.FromDays(-1),
            Related = TriggerRelation.Start
        }
    };

    // Add an alarm (reminder) for the event
    eventTraineeReview.Alarms.Add(alarmTraineeReview);

    // Add the event to the calendar
    calendar.Events.Add(eventTraineeReview);

    CalendarSerializer serializer = new CalendarSerializer();
    string icsContent = serializer.SerializeToString(calendar);

    // Save the calendar content to a file.
    string calendarSavePath = System.IO.Path.Combine("C:\\Temp\\", string.Format("{0}-IcsEmail.txt", DateTime.Now.ToString("yyyyMMddHHmmssfff")));
    System.IO.File.AppendAllText(calendarSavePath, icsContent);

    return serializer.SerializeToString(calendar);
}

I have also supplied two text files showing the resulting ICS content for each event date. It seems that the the formatting of the value for DTSTART and DTEND dates differ between the two.

StartDate-31-10-2016-Ics.txt
StartDate-30-10-2016-Ics.txt

This is happening in Outlook 2013.

Error serializing TimeSpan.Zero

The TimeSpanSerializer doesn't correctly serialize 0.
This is needed for alarm triggers at event start time for example which, should look like
TRIGGER:P0D
Instead the Serializer only generates:
TRIGGER:P

Bug was also already present in DDay.iCal

Add support for .NET Core

• Get rid of Hashtable usage in ANTLR parser
• Get rid of ArrayList usage in ANTLR parser

What is the correct Logic to obtain unique Id of recurring meeting instances

I am implementing logic that will allow a user to upload ICS files and import a number of meetings/events into a DB.

For single instance meetings, I can just use the Uid to check if we already have the meeting.

For recurring meetings though, I'd like to clarify what logic I should use to correctly get a unique Id for each instance of the recurring meeting series.

Are the following statements correct?

If the RecurrenceRules collection contains any items then the event is a recurring meeting instance and I should use the StartTime field from the occurrence Period as a unique identifier for that instance. The Start field from the event itself contains the start date of the recurring series and not of the individual instance.

If the RecurrenceID field is populated then this should be used as the unique identifier for the instance. My understanding is that this field will only be populated for exceptions to the recurring meeting series and will contain updated information for a single instance of a recurring meeting series.
The Sequence field indicates that there can be multiple updates to a instance of a recurring meeting. The highest sequence number should contain the most recent changes to the instance.

Is there any wrapper method available that has already implemented logic to determine the recurring event ID and I can use that instead of having to implement my own logic?

Get Featured as Nuget Package Of The Week

@rianjs when you are ready, I can shoot this package over to someone at Microsoft and try to get it featured as a Nuget package of the week.

Broken Example: Thanksgiving

The example for Thanksgiving (https://github.com/rianjs/ical.net/wiki/Working-with-recurring-elements#the-fourth-thursday-of-every-november) produces the wrong results:

• Occurrence: 11/23/2000 12:00:00 AM -- Thursday
• Occurrence: 11/23/2001 12:00:00 AM -- Friday
• Occurrence: 11/23/2002 12:00:00 AM -- Saturday
• Occurrence: 11/23/2003 12:00:00 AM -- Sunday
• Occurrence: 11/23/2004 12:00:00 AM -- Tuesday
• Occurrence: 11/23/2005 12:00:00 AM -- Wednesday
• Occurrence: 11/23/2006 12:00:00 AM -- Thursday
• Occurrence: 11/23/2007 12:00:00 AM -- Friday
• Occurrence: 11/23/2008 12:00:00 AM -- Sunday
• Occurrence: 11/23/2009 12:00:00 AM -- Monday
• Occurrence: 11/23/2010 12:00:00 AM -- Tuesday
• Occurrence: 11/23/2011 12:00:00 AM -- Wednesday
• Occurrence: 11/23/2012 12:00:00 AM -- Friday
• Occurrence: 11/23/2013 12:00:00 AM -- Saturday
• Occurrence: 11/23/2014 12:00:00 AM -- Sunday
• Occurrence: 11/23/2015 12:00:00 AM -- Monday
• Occurrence: 11/23/2016 12:00:00 AM -- Wednesday

I am trying (and failing) to figure out how to build a recurrence rule for Thanksgiving... Could you update the example?

Thanks!

Nuget tweaks: NodaTime, logo url, .NET 3.5 support

• NodaTime: right now, NodaTime.dll is packaged up behind the scenes. It should really be specified in the nuspec file.
• We have no logo url specified, but @khalidabuhakmeh has made us a logo, so let's use it
• It should be possible to package a .NET 3.5 version of ical.net, which should increase target framework overlap with the original dda.ical, so let's do that ConcurrentDictionary doesn't exist in .NET 3.5. Oh well.

Does ical.net.collections need to exist?

Hypothesis: they can be replaced by standard .NET collections.

Background: profiling the unit test runtimes shows slow GetEnumerator performance quite often (5ms+). This is an eternity in CPU time. For normal .NET collections, getting the enumerator is basically unmeasurable. Even if we retain the same interfaces, perhaps the backing collections can be made more standard.

One or more packages are incompatible with .NETCoreApp Version=v1.0

Will there be support for netcoreapp1.0 in the near future? Temporarily I can target net46 but unfortunately that isn't a great long term solution for us.

iCalParser.cs should use StringBuilders instead of concatenation

E.g. iCalParser.number()

Serialize inserting 0x0A 0x0D

I'm testing the serialization to string and I'm seeing that DESCRIPTION is inserting 0x0A 0x0D chars which causes problems when importing the .ics file into google or outlook. The code look like:

    var calendar = new Calendar();
            var e = new Event {
            Uid = guid,
            Summary = name,
            Description = description,
            Location = venue,
            Status = eventStatus,
            DtStart = new CalDateTime(start),
            DtEnd = new CalDateTime(end),
        };
    calendar.Events.Add(e);

    var serializer = new CalendarSerializer(new SerializationContext());
    var serializedCalendar = serializer.SerializeToString(calendar);
    File.WriteAllText(exportFilename, serializedCalendar);

CalendarCollection Equals and GetHashCode need attention

While writing the LoadFromUri example replacements for the Migrating from dday.ical wiki page, I discovered that CalendarCollection doesn't have reasonable equality or hashing semantics. Should be a straightforward fix.

Using Calendar.AddProperty duplicates property name into value

This may be myself not understanding the spec for ics/ical files however when using .AddProperty(string, string) on a calendar the property name gets added twice.

For example using the following:

Calendar cal = new Calendar();
cal.AddProperty("test", "123");

Will give a serialised result with the following:

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//github.com/rianjs/ical.net//NONSGML ical.net 2.1//EN
test:test:123

It also gets prepended to the value of the property on the calendar object, so its not a serialisation issue.

Edit:

I've just tried the same using the CalanderProperty class and its (string, string) constructor, seem to have the same issue: cal.AddProperty(new CalendarProperty("123", "test")); will result in 123:123:test, so again the name 123 and a colon is being prepended to the value of the property object

This also happens when adding properties to events.

Attendees can't be removed once added

Repro:

public void Remove1Attendee()
{
    var evt = VEventFactory(); //some new event
    Assert.AreEqual(0, evt.Attendees.Count);

    var attendee = _attendees.First();
    evt.Attendees.Add(attendee);
    Assert.AreEqual(1, evt.Attendees.Count);

    evt.Attendees.Remove(attendee);
    Assert.AreEqual(0, evt.Attendees.Count);
}

Get rid of the magic strings and ambiguous properties for attachment encoding

ical.net/ical-core/ical.net/src/ical.net/Serialization/EncodingProvider.cs

Line 58 in 8c34b30

protected virtual DecoderDelegate GetDecoderFor(string encoding)

^^ That's not great. And should users use the ValueEncoding or Encoding property? It's not at all clear.

Reference NodaTime as an external dependency, instead of packaging the binary directly

Will have to wait until 2.0 is out of pre-release so as not to go backward WRT the .NET Core port.

Continuation of #72

TimeZone deserialization RDATE property value as string rather than IDateTime

Title says it all - I'll put up a pull request for a test demonstrating.

RecurrencePatternEvaluator.cs uses for loops to do set (UnionWith, ExceptWith) operations

Let's make them sets.

UIDs should be *optionally* auto-generated.

While there, make sure that they're only implemented for VEVENT, VTODO, VJOURNAL, and VFREEBUSY blocks, per the spec:

http://www.kanzaki.com/docs/ical/uid.html

Error serializing VTODO with DUE and DURATION

When setting a task DUE date, also a DURATION is serialized.
According to the RFC5545:

              ; Either 'due' or 'duration' MAY appear in
              ; a 'todoprop', but 'due' and 'duration'
              ; MUST NOT occur in the same 'todoprop'.
              ; If 'duration' appear in a 'todoprop',
              ; then 'dtstart' MUST also appear in
              ; the same 'todoprop'.

This bug was also present in DDay.iCal.

DTSTAMP should be in UTC without TimeZone property

As of RFC 4.8.7.2 Date/Time Stamp here or here the DTSTAMP property should be of UTC but without the TimeZone property.

Unfortunately (as I see it) we have no influence on this particular DateTime property during serialization.

Or do you have any ideas how to strip the TZID when serialize this property?

EnsureProperties() method
Additionally and in this matter I propose the followin code change for the default value of DTSTAMP:

if (DtStamp == null)
{
var now = DateTime.SpecifyKind(DateTime.Today.Add(DateTime.UtcNow.TimeOfDay), DateTimeKind.Utc);
DtStamp = new CalDateTime(now);
}

This way the CalDateTime() variable has the property IsUniversalTime set true.

Original:

if (DtStamp == null)
{
  // Here, we don't simply set to DateTime.Now because DateTime.Now contains milliseconds, and
  // the iCalendar standard doesn't care at all about milliseconds.  Therefore, when comparing
  // two calendars, one generated, and one loaded from file, they may be functionally identical,
  // but be determined to be different due to millisecond differences.
  var now = DateTime.Now;
  DtStamp = new CalDateTime(now.Year, now.Month, now.Day, now.Hour, now.Minute, now.Second);
}

From here.

The problem is we get the followin output when serializing:

BEGIN:VCALENDAR
PRODID:TESTCAL
VERSION:2.0
X-WR-CALNAME:X-WR-CALNAME:Test
BEGIN:VEVENT
DESCRIPTION:Description
DTEND;TZID=W. Europe Standard Time:20160804T150000
DTSTAMP;TZID=UTC:20160804T110635Z
DTSTART;TZID=W. Europe Standard Time:20160804T140000
SEQUENCE:0
SUMMARY:Test-Event
UID:1234
END:VEVENT
END:VCALENDAR

With ical-validator we get Parser error at line 8: Cannot set timezone for UTC properties.

When removed we have no errors.

Target RFC5545 and possibly RFC7265

Hey this may just an oversight but I noticed the readme said:

It's aimed at providing full RFC 2445 compliance

RFC 2445 was made obsolete by RFC5545 so we should probably target that instead. Also, I was wondering if there was a roadmap to use jCal according to (RFC7265)?

https://tools.ietf.org/html/rfc5545
https://tools.ietf.org/html/rfc7265

Multi-line attachments are not serialized correctly

Generating binary data for attachments is fine, but the Base64-encoded data is not serialized correctly. Here's a repro case with output:

public void BinaryAttachment_Tests()
{
    var asBytes = Encoding.UTF8.GetBytes("This is a song that never ends. It just goes on and on my friends. Some people started singing it not...");
    var attachment = new Attachment
    {
        Data = asBytes,
        ValueEncoding = Encoding.UTF8,
    };

    var calendar = new Calendar();
    var vEvent = GetSimpleEvent();
    vEvent.Attachments = new List<IAttachment> { attachment };
    calendar.Events.Add(vEvent);

    var serialized = SerializeToString(calendar);
    var unserialized = UnserializeCalendar(serialized);

    Assert.AreEqual(calendar.GetHashCode(), unserialized.GetHashCode());
    Assert.AreEqual(calendar, unserialized);
}

The output is incorrect. There should be spaces on the wrapped lines. This is causing deserialization to fail, because the regex is looking for \r\n[ \t] in TextUtil.UnwrapLines:

BEGIN:VCALENDAR
PRODID:-//github.com/rianjs/ical.net//NONSGML ical.net 2.1//EN
VERSION:2.0
BEGIN:VEVENT
ATTACH;VALUE=BINARY;ENCODING=BASE64:VGhpcyBpcyBhIHNvbmcgdGhhdCBuZXZlciBlbmR
zLiBJdCBqdXN0IGdvZXMgb24gYW5kIG9uIG15IGZyaWVuZHMuIFNvbWUgcGVvcGxlIHN0YXJ0Z
WQgc2luZ2luZyBpdCBub3QuLi4=
DTEND:20160721T145800
DTSTAMP:20160721T135802
DTSTART:20160721T135800
SEQUENCE:0
UID:d5437779-9ad2-4781-a1ee-c554f10594a6
END:VEVENT
END:VCALENDAR

VTimeZone.FromSystemTimeZone method does not create DAYLIGHT or STANDARD collections

The spec mandates that timezone contain at least 1 of these elements. Will post some tests which demonstrate.

Investigate non-binary attachments, and document their use

Extend the docs (and make sure there are no bugs!) around non-binary attachments. Write some unit tests proving that string attachments work properly, and serialization is symmetrical.

Supporting WinRT platform

I need this library for WinRT platform. I created separate project and moved your code to this project. I moved tests too. So now I have working library for WinRT.

I can put it on github as different library. But I'm afraid that nobody'll improve this library in the future.
Do you need this code? Can you implement it to your project?

Re-evaluate deserialization

Passing valid VEVENT text to the Event constructor is a natural thing to want to do. Unfortunately the current deserialization approach doesn't allow for this.

Similarly, passing an icalendar string to a CalendarCollection constructor (or similar) should allow you to create that representation.

Basically, serialization should feel natural, and almost invisible to the user.

Get rid of dday.ical mention in nuget package title

The old dday.ical package tells people to use ical.net right in the title. Calling it ical.net looks less ridiculous.

Create an iCal.NET logo

Here are some options :). I prefer the first one.

Add mcshaz to the contributors list

Assigning to @mcshaz :) -- It's in contributors.md

Serialized input -> Deserialization -> Reserialization should be symmetrical

The previous nuget release (2.1.3) was not serializing any of the timezone info, but was serializing events (albeit setting any and all attendee properties other than uri to null as part of the Attendees.Add operation).

In the current github master branch, events are not serialized either.

Test cases are included with a pull request, but as a brief example:

using (var cal = new Calendar() { Method = "PUBLISH", Version = "2.0" })
{
    var evt = new Event
    {
         Summary = "Testing",
         Start = new CalDateTime(2010, 3, 25),
         End = new CalDateTime(2010, 3, 26)
     }
    cal.Events.Add(evt);
    var serializer = new CalendarSerializer(new SerializationContext());
    var serializedCalendar = serializer.SerializeToString(cal);
}

will currently produce

BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:-//github.com/rianjs/ical.net//NONSGML ical.net 2.1//EN
VERSION:2.0
END:VCALENDAR

Setup Continuous Integration

This project should setup a CI build server to do the following:

• Build every incoming PR against master
• Run all existing and new unit tests
• Attempt to build and deploy to Nuget if the version is bumped.

This will help foster more collaboration and an understanding of why or why not a PR can be merged.

Also, as a side note: look into https://lgtm.co as potential point of collaboration.

Write a "migrating from dday.ical" wiki page

https://github.com/rianjs/ical.net/wiki/Migrating-from-dday.ical

Enums in capital case, not all upper case

First - huge thank you and kudos for getting this project under active development once again!

Setting the properties for an event instance, for example as below:

myEvt.Transparency = TransparencyType.Opaque;
myEvt.Status = EventStatus.Confirmed;

results in a serialised string with the following text:
STATUS:Confirmed
TRANSP:Opaque

this does not validate, as the string should be
STATUS:CONFIRMED
TRANSP:OPAQUE

prevent assignment of simple IList to event and attendees collections

Collections, such as the calender's Event collection, and the event's Attendee collection are of type IList<>, with public getters and setters.

The problem is that it gives the idea that the collection can/should be assigned from any list or array, eg. (pseudocode)
evt.Attendees = context.People.Select(p=>new Attendee (p.Email){ CommonName = p.name }).ToList()
the above approach has hitherto not serialized to a string properly.

obvious solutions to this are

• having internal setters,
• or making sure the assigned property implements a different interface, e.g. IGroupedCollection<,>

a more difficult solution would be to serialize the IList correctly, as it appears (from the example page) to occur with RecurrenceRules

objectType.GetTypeInfo().IsEnum doesn't work in .NET 4.0

From #23 (comment) :

objectType.GetTypeInfo().IsEnum in SerializerFactory works in .NET 4.5+, but not in .NET 4.0. Maybe we need an ifdef. Ugh.

Maybe:
http://stackoverflow.com/questions/3436526/detect-target-framework-version-at-compile-time

API changes for v3

Get rid of:

• LoadFromFile (replacement = strings)
• LoadFromUri: the web is a lot different than it used to be. Having ical.net handle the download logic takes specific dependencies on specific framework elements. It reduces the library's ability to iterate. I would prefer to leave HttpClient out of it, which some client profiles may not support. Application developers can provide their own download-from-source implementation if they wish.

VTimeZone:

• Just make the user specify a time zone string. Get rid of the FromSystemTimeZone and FromLocalTimeZone stuff which isn't well-defined in a cross-platform world.

Attachment:

• Data properties on Attachments should be getter-only
• There should be a constructor flavor that takes a byte[] that does the right thing WRT to base64-encoding on both serialization and deserialization

Misc:

• Target netstandard 1.1

Add tags to nuspec file

Tags are empty. That's dumb.

• iCal
• Calendar
• icalendar
• ics
• outlook
• events
• rfc 5545
• rfc 2445

Error parsing VTIMEZONES from tzurl.org

When trying to load a timezone with Calendar.LoadFromStream() from tzurl.org, e.g. http://tzurl.org/zoneinfo/Europe/Berlin.ics
I get the following exception

System.FormatException: Die Zeichenfolge wurde nicht als gültiges DateTime erkannt.
   bei System.DateTimeParse.Parse(String s, DateTimeFormatInfo dtfi, DateTimeStyles styles, TimeSpan& offset)
   bei System.DateTimeOffset.Parse(String input)
   bei Ical.Net.Serialization.iCalendar.Serializers.DataTypes.UtcOffsetSerializer.GetOffset(String rawOffset) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\Serializers\DataTypes\UTCOffsetSerializer.cs:Zeile 42.
   bei Ical.Net.DataTypes.UtcOffset..ctor(String value) in C:\dev\ical.net\ical.NET\DataTypes\UTCOffset.cs:Zeile 26.
   bei Ical.Net.Serialization.iCalendar.Serializers.DataTypes.UtcOffsetSerializer.Deserialize(TextReader tr) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\Serializers\DataTypes\UTCOffsetSerializer.cs:Zeile 32.
   bei Ical.Net.Serialization.iCalendar.Serializers.DataMapSerializer.Deserialize(TextReader tr) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\Serializers\DataMapSerializer.cs:Zeile 56.
   bei Ical.Net.Serialization.iCalendar.iCalParser.property(ISerializationContext ctx, ICalendarPropertyListContainer c) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\iCalParser.cs:Zeile 292.
   bei Ical.Net.Serialization.iCalendar.iCalParser.component(ISerializationContext ctx, ISerializerFactory sf, ICalendarComponentFactory cf, ICalendarObject o) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\iCalParser.cs:Zeile 415.
   bei Ical.Net.Serialization.iCalendar.iCalParser.component(ISerializationContext ctx, ISerializerFactory sf, ICalendarComponentFactory cf, ICalendarObject o) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\iCalParser.cs:Zeile 420.
   bei Ical.Net.Serialization.iCalendar.iCalParser.icalbody(ISerializationContext ctx, ICalendar cal) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\iCalParser.cs:Zeile 207.
   bei Ical.Net.Serialization.iCalendar.iCalParser.icalendar(ISerializationContext ctx) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\iCalParser.cs:Zeile 144.
   bei Ical.Net.Serialization.iCalendar.Serializers.CalendarSerializer.Deserialize(TextReader tr) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\Serializers\iCalendarSerializer.cs:Zeile 81.
   bei Ical.Net.Serialization.iCalendar.Serializers.SerializerBase.Deserialize(Stream stream, Encoding encoding) in C:\dev\ical.net\ical.NET\Serialization\iCalendar\Serializers\SerializerBase.cs:Zeile 39.
   bei Ical.Net.Calendar.LoadFromStream(Stream s, Encoding e, ISerializer serializer) in C:\dev\ical.net\ical.NET\Calendar.cs:Zeile 113.
   bei Ical.Net.Calendar.LoadFromStream(TextReader tr, ISerializer serializer) in C:\dev\ical.net\ical.NET\Calendar.cs:Zeile 137.
   bei Ical.Net.Calendar.LoadFromStream(TextReader tr) in C:\dev\ical.net\ical.NET\Calendar.cs:Zeile 118.

UTC DateTime not serialising to spec

the date

LastModified = new CalDateTime(DateTime.SpecifyKind(new DateTime(2010, 3, 27, 13, 53, 35), DateTimeKind.Utc))

is serialising as:

LAST-MODIFIED;TZID=UTC:20100327T135335Z

the standard states:
The "TZID" property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC.

(This was found using the test in my 'experimental' branch posting a serialised calendar object to icalendar.org for validation)

Issue with deleted recurring events

I'm having an issue with exceptions to recurring events, specifically date exceptions that should be omitted when you call GetOccurences.

In my sample file, i have:
RRULE:FREQ=WEEKLY;COUNT=35;BYDAY=TU,TH
EXDATE;TZID=America/Los_Angeles:20160823T123000
EXDATE;TZID=America/Los_Angeles:20160818T123000
EXDATE;TZID=America/Los_Angeles:20160816T123000

When I call GetOccurences, only the first exdate is omitted, but the others are still present.
I looked at event.ExceptionDates, and all 3 are present. I dug in and found out that something is happening in the Evaluate function. On line 32 in PeriodListEvaluator.cs - periods.UnionWith(_mPeriodList); _mPeriodList only has the first exception date in it. The other 2 are missing. So when the union is done, only the first exception date is retained. I haven't been able to figure out why the PeriodList isn't getting the other 2 dates.

Any ideas? Is this known? I believe when I had all the exception dates comma separated on one line it worked..

Documentation: Working with recurrences

https://github.com/rianjs/ical.net/wiki/Working-with-recurring-elements

Work in progress...

Evaluate CopyFrom usage

I suspect most of it is unnecessary.

Add support for jCal (RFC-7529) a JSON format for iCalendar data

https://tools.ietf.org/html/rfc7529

https://stackoverflow.com/questions/35757778/rrule-for-repeating-monthly-on-the-31st-or-closest-day

UTC midnight is assumed not to have a timezone component

Many properties, in order to meet the spec, should have a dateTime in UTC

currently, the CalDateTime Initializer method has the code HasTime = value.Second != 0 || value.Minute != 0 || value.Hour != 0;

that is to say if the developer want's to set a time for the DtStart property of a FreeBusy component, the period they want starts at 8 am and they are on a +08:00 timezone (25% of the world's population live in this timezone!), they have to know to explicitly set HasTime = True in order to serialize correctly, and they would presumably not even be thinking what the UTC time is.

I would propose creating a CalDate class which inherits from CalDateTime, and has constructors accepting year, month, day or a DateTime, and sets the HasTime property to false (I would also make the setter for HasTime protected, with the base CalDateTime implementation always returning True (i.e. not performing the check in the initilizer function above), although that would be a breaking change and so possibly best done in a step wise pattern with an obsolete attribute on the setter).

in the interim, I could make the assignment to HasTime in the initializer a tiny bit more robust with something like HasTime = IsUniversalTime || value.TimeOfDay.Ticks!=0;

Thoughts? Could you suggest a better pattern?

Thank you for your patience with all these issues.

Calendar.LoadFromStream is not thread safe

System.ArgumentException occurred
  HResult=-2147024809
  Message=An item with the same key has already been added.
  Source=mscorlib
  StackTrace:
       at System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
       at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
       at Ical.Net.Utility.SerializationUtil.GetDeserializingMethods(Type targetType) in C:\dev\ical.net\ical.NET\Utility\SerializationUtil.cs:line 60
  InnerException:

Repro case. Code works fine if .AsParallel() is removed.

public static IEnumerable<DowntimeWithExactTimes> GetDowntimesInRange(IEnumerable<Downtime> downtimes, DateTime earliestStart, DateTime latestEnd)
{
    var sw = new Stopwatch();
    sw.Start();
    var earliestStartIcal = new CalDateTime(earliestStart, "UTC") {HasTime = true};
    var latestEndIcal = new CalDateTime(latestEnd, "UTC") {HasTime = true};
    var downtimesWithExactTimes = downtimes.AsParallel().SelectMany(downtime =>
    {
        IICalendarCollection calendar;
        using (var reader = new StringReader(downtime.IcalString ?? ""))
        {
            // Originally calendar = iCalendar.LoadFromStream(reader), but that uses a static serializer so it isn't thread safe.
            //calendar = Calendar.LoadFromStream(reader);
            calendar = Calendar.LoadFromStream(reader, new CalendarSerializer { SerializationContext = new SerializationContext() });
        }

        var thisDowntime = downtime;
        var occurrences = calendar.GetOccurrences(earliestStartIcal, latestEndIcal);
        return occurrences.Select(occurrence => new DowntimeWithExactTimes(thisDowntime, occurrence.Period.StartTime.AsUtc, occurrence.Period.EndTime.AsUtc));
    });
    var orderedDowntimes = downtimesWithExactTimes.OrderBy(downtime => downtime.Start).ThenBy(downtime => downtime.End).ToList();
    sw.Stop();
    return orderedDowntimes;
}

Reflow DDay.ICal Nuget Package To ICal.Net

I will reflow the Nuget package as soon as the infinite redirect loop is solved on https://nuget.org. I'd much prefer people are lead to your package, and I believe the stats will jump over too. So it will make ICal.Net more relevant, but don't quote me on it :)

v3 suggestion - more consistent valid property values

I am not hugely familiar with the library, and I may have missed important features of the library in which case I apologise. Assigning values to properties with a limited number of valid values under the spec seems inconsistent.

The Event property Class is a string, and the developer must know (or look up) valid values are "PUBLIC" or "PRIVATE", the same for an Attendee property Role (e.g. "REQ-PARTICIPANT").

the Event properties Transparency and Status are Enums.

An Attendee ParticipationStatus string property can be assigned from the const strings in the ParticipationStatus namespace. The same applies to the Calendar Method property and the CalendarMethods namespace

It would seem ideal if the above 6 properties all had a similar method of asignment.

Thanks

Type or namespace Ical could not be found

I've followed your tutorial on the wiki and the following namespaces are not found
using Ical.Net;
using Ical.Net.DataTypes;
using Ical.Net.Serialization.iCalendar.Serializers;

I'm using version 2.2.6.

How can I fix this?