Not all valid iCalendar Date/Date-Time formats can be parsed

[leesharma]

Current Behavior

Some of the valid date/date-time formats (as defined in RFC 2445) are not parsable.
For example, when trying to parse a DTSTART using a datetime with the local timezone:

iex> ical = """
            BEGIN:VEVENT
            DTSTART:19690620T201804
            END:VEVENT
            """ # local time
iex> ExIcal.parse ical
** (FunctionClauseError) no function clause matching in ExIcal.DateParser.parse/2
    (ex_ical) lib/ex_ical/date_parser.ex:7: ExIcal.DateParser.parse("19690620T201804", nil)
    (ex_ical) lib/ex_ical/parser.ex:15: ExIcal.Parser.parse_line/2
     (elixir) lib/enum.ex:1623: Enum."-reduce/3-lists^foldl/2-0-"/3
    (ex_ical) lib/ex_ical/parser.ex:8: ExIcal.Parser.parse/1

From what I can tell, Form 1 and Form 3 (below) are not currently handled.

Expected Behavior

I'd expect all formats defined in the specs to be parsable by this library.
There are four valid input forms:

• Form 1: Date-Time with local time (19690620T201804)
• Form 2: Date-Time with UTC time (19690620T201804Z)
• Form 3: Date-Time with local time + time zone reference (TZID=America/Chicago:19690620T201804)
• Form 4: Date (19690620)

Also, these inline time zones need to interact in a reasonable way with the global calendar time zones–inline time zones (Forms 2 & 3) should take precedence over global zones.

Here are some possible rules:

#	Example Line	When no global TZID is set	When TZID:Europe/Berlin
1	DTSTART:19690620	No timezone (date)	No timezone (date)
2*	DTSTART:19690620Z	No timezone (date)	No timezone (date)
3	DTSTART:19690620T201804	No timezone (local)	Europe/Berlin
4	DTSTART:19690620T201804Z	UTD	UTD (priority to zulu time marker)
5	DTSTART;TZID=America/New_York:19690620T201804	America/New_York	America/New_York (priority to inline tzid)
6*	DTSTART;TZID=America/New_York:19690620T201804Z	UDT (priority to zulu time marker)	UDT (priority to zulu time marker)

*L2 & L6 are not in the spec, but I included them here for error tolerance

System Information

• ExIcal: observed on 0.0.3
• Elixir: 1.3.2
• Erlang/OTP: 19
• OS: Mac OS X 10.11.5

[leesharma]

Actually, one complication–it looks like dates do actually need to be in a timezone so that they can be searched/ordered (for example, when using ExIcal.by_range/3)

Maybe this?

#	When no global TZID is set	When TZID:Europe/Berlin
1	Local timezone**	Europe/Berlin**
2*	UDT**	UDT (priority to zulu time marker)**
3	Local timezone**	Europe/Berlin
4	UTD	UTD (priority to zulu time marker)
5	America/New_York	America/New_York (priority to inline tzid)
6*	UDT (priority to zulu time marker)	UDT (priority to zulu time marker)

** New timezones

It looks like Timex.Timezone.local/0 exists, though could that cause issues since it's not deterministic? Maybe defaulting to UDT would be better?

This will also make converting back difficult–we'd be loosing the fact that these are "floating" dates. Maybe a field should be added to %Timex.Event{} (maybe floating: true) to store that information?