The reason you're keeping a calendar is so you can manage and keep track of your time efficiently. So, it isn't a surprise that some of the most interesting (and complex) iCalendar properties are those related to the specifying of Time.
iCalendar is an Internet protocol, and since the net spans the globe and people from different timezones need to make appointments with each other more and more, it's important that they can agree on a time, despite the difficulties of timezones, daylight savings time, etc.
The simplest way of expressing dates is YYYYMMDD, for instance 20010114 for the 14th of January 2001.
Times can be expressed similarly, as HHMMSS (eg 190000 for 7pm). This is used for local time. However, if you want to fix a time properly, you'll have to put a Z on the end (for “Zulu”, the military name for the UTC timezone). For example: a telephone meeting scheduled between people in different timezones should have its time specified in UTC using the HHMMSSZ format, but a reminder to oneself to go to the gym at 7pm every day should be specified in local time so that it would still occur in the early evening even if one travelled across timezones.
To specify a date and time together, simply put the date, then a T, then the time: 20010114T190000Z
Sometimes, instead of an end time, one might choose to specify a duration. It comes to essentially the same thing, but makes more sense in some circumstances. The format for duration is slightly odd: it starts with a P (for Period), then has numbers and letters, with letters representing the units and numbers representing how many of them there are. For instance, H is for hours, so 4H would be four hours. Therefore a duration of 2 hours 30 minutes would be specified as P2H30M.
Syntax for dates, times and durations is described more fully in sections 4.3.4, 4.3.5, 4.3.6 and 4.3.12 of RFC2445.
One complex subject is the handling of recurring events, which is documented in section 4.8.5 of RFC2445.
A recurring event has a DTSTART property which specifies its first occurence, then a set of rules which can be parsed to find the “recurrence set”, or the list of dates and times on which the event will recur.
Recurrence is specified using the RRULE, RDATE, EXRULE and EXDATE properties.
RRULE describes a rule for finding recurrence, for instance “daily until the 20th September”. RDATE specifies a list of specific dates/times. Obviously the former is more useful for regularly recurring events, whereas the second is more suited to those which are repeated on an ad-hoc basis.
EXRULE and EXDATE are similar, but describe exceptions to the recurrence list. For instance, an RRULE which said “daily” and an EXRULE which said “weekly on Tuesdays” would combine to mean “every day except Tuesdays”. Similarly, an EXDATE property could be used to specify specific dates on which the event would not recur, such as public holidays.