Valid DTSTART values (specifically DATE type) are encoded as `nil` for events

[dabaer]

Given an event that contains a DATE only value for DTSTART and DTEND, the event fields are set to nil. I initially thought having a plain date was against the spec as icalendar also had this issue but I found sections of the literature that seem to imply date-only is valid:

https://datatracker.ietf.org/doc/html/rfc5545#section-3.8.2.4

Value Type: The default value type is DATE-TIME. The time value
MUST be one of the forms defined for the DATE-TIME value type.
The value type can be set to a DATE value type.

It also prescribes a case for this in VEVENT: https://datatracker.ietf.org/doc/html/rfc5545#section-3.6.1

For cases where a "VEVENT" calendar component
specifies a "DTSTART" property with a DATE value type but no
"DTEND" nor "DURATION" property, the event's duration is taken to
be one day.

Here is an example file that has this issue:

BEGIN:VCALENDAR
METHOD:PUBLISH
PRODID:ExampleProd
VERSION:2.0
X-WR-CALNAME:ExampleName
X-WR-TIMEZONE:America/Edmonton
BEGIN:VTIMEZONE
TZID:America/Edmonton
X-LIC-LOCATION:America/Edmonton
BEGIN:STANDARD
DTSTART:20241103T020000
RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=11
TZNAME:MST
TZOFFSETFROM:-0600
TZOFFSETTO:-0700
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20250309T020000
RRULE:FREQ=YEARLY;BYDAY=2SU;BYMONTH=3
TZNAME:MDT
TZOFFSETFROM:-0700
TZOFFSETTO:-0600
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
CREATED;TZID=America/Edmonton:20260406T000000
DTEND;TZID=America/Edmonton;VALUE=DATE:20260530
DTSTAMP;TZID=America/Edmonton:20260406T000000
DTSTART;TZID=America/Edmonton;VALUE=DATE:20260529
SEQUENCE:2026052815
SUMMARY:ExampleSummary
UID:ExampleID
X-FUNAMBOL-ALLDAY:1
X-MICROSOFT-CDO-BUSYSTATUS:BUSY
END:VEVENT
END:VCALENDAR

I'm not sure which library the ical is produced with, but judging by the data source it is ASP.net or similarly based, and the file is parsed correctly by Apple Calendar, as well as Microsoft Outlook.

Here is the resulting event:

%ICal.Event{
    uid: "ExampleID",
    dtstamp: #DateTime<2026-04-06 00:00:00-06:00 MDT America/Edmonton>,
    created: #DateTime<2026-04-06 00:00:00-06:00 MDT America/Edmonton>,
    dtstart: nil,
    dtend: nil,
    ...
}

I did end up bodging this in our fork of icalender but the solution wasn't very nice (and used Timex):

case Timex.parse(date_string <> timezone, "{YYYY}{0M}{0D}Z{Zname}") do
    {:ok, dt} -> {:ok, dt}
    {:error, _} ->
      Timex.parse(date_string <> timezone, "{YYYY}{0M}{0D}T{h24}{m}{s}Z{Zname}")
  end
end

I'd be willing to implement something similar here with Calendar and parsing the value type unless there's something else I'm missing.

[dabaer]

Whoops, I should have checked the source of date parsing first sorry. I see date value types are handled:

def to_date(date_string, %{"VALUE" => "DATE"}, _calendar) do
  # of the form {YYYY}{MM}{DD}
  with <<y::binary-size(4), m::binary-size(2), d::binary-size(2)>> <- date_string,
       {year, ""} <- Integer.parse(y),
       {month, ""} <- Integer.parse(m),
       {day, ""} <- Integer.parse(d),
       {:ok, date} <- Date.new(year, month, day) do
    date
  else
    _ -> nil
  end

I'll dig into the issue on my end further.

[aseigo]

Does the application have a timezone database installed?

The test file has X-WR-TIMEZONE:America/Edmonton in the top, so all date-related data will be put into that timezone. In testing with an application with a timezone database, I get:

%ICal{
  product_id: "ExampleProd",
  scale: "GREGORIAN",
  method: "PUBLISH",
  version: "2.0",
  events: [
    %ICal.Event{
      uid: "ExampleID",
      dtstamp: #DateTime<2026-04-06 00:00:00-06:00 MDT America/Edmonton>,
      created: #DateTime<2026-04-06 00:00:00-06:00 MDT America/Edmonton>,
      dtstart: nil,
      dtend: nil,
      modified: nil,
      recurrence_id: nil,
      exdates: [],
      rdates: [],
      rrule: nil,
      class: nil,
      description: nil,
      duration: nil,
      location: nil,
      status: nil,
      organizer: nil,
      sequence: 2026052815,
      summary: "ExampleSummary",
      url: nil,
      geo: nil,
      priority: nil,
      transparency: nil,
      alarms: [],
      attachments: [],
      attendees: [],
      categories: [],
      comments: [],
      contacts: [],
      related_to: [],
      resources: [],
      request_status: [],
      custom_properties: %{
        "X-FUNAMBOL-ALLDAY" => %{value: "1", params: %{}},
        "X-MICROSOFT-CDO-BUSYSTATUS" => %{value: "BUSY", params: %{}}
      }
    }
  ],
  todos: [],
  journals: [],
  timezones: %{
    "America/Edmonton" => %ICal.Timezone{
      id: "America/Edmonton",
      modified: nil,
      url: nil,
      standard: [
        %ICal.Timezone.Properties{
          dtstart: ~N[2024-11-03 02:00:00],
          offsets: %{to: -700, from: -600},
          rrule: %ICal.Recurrence{
            until: nil,
            count: nil,
            by_second: nil,
            by_minute: nil,
            by_hour: nil,
            by_day: [{1, :sunday}],
            by_month_day: nil,
            by_year_day: nil,
            by_month: ~c"\v",
            by_set_position: nil,
            by_week_number: nil,
            week_start_day: :default,
            frequency: :yearly,
            interval: 1
          },
          comments: [],
          rdates: [],
          names: ["MST"],
          custom_properties: %{}
        }
      ],
      daylight: [
        %ICal.Timezone.Properties{
          dtstart: ~N[2025-03-09 02:00:00],
          offsets: %{to: -600, from: -700},
          rrule: %ICal.Recurrence{
            until: nil,
            count: nil,
            by_second: nil,
            by_minute: nil,
            by_hour: nil,
            by_day: [{2, :sunday}],
            by_month_day: nil,
            by_year_day: nil,
            by_month: [3],
            by_set_position: nil,
            by_week_number: nil,
            week_start_day: :default,
            frequency: :yearly,
            interval: 1
          },
          comments: [],
          rdates: [],
          names: ["MDT"],
          custom_properties: %{}
        }
      ],
      custom_properties: %{
        "X-LIC-LOCATION" => %{value: "America/Edmonton", params: %{}}
      }
    }
  },
  default_timezone: "America/Edmonton",
  name: "ExampleName",
  custom_properties: %{
    "X-WR-CALNAME" => %{value: "ExampleName", params: %{}},
    "X-WR-TIMEZONE" => %{value: "America/Edmonton", params: %{}}
  },
  __other_components: []
}

So it parses properly, but as shown above the dates are put into the timezone in the file.

This is documented (needing a timezone database) in the README, which is also the default page in the docs .. but you're not the first to run into this issue (if that is indeed the problem). I have been hesitant to force a timezone database, but perhaps ICal should just hard-depend on of the two Elixir timezone libraries that actually work ... it would be unfortunate for those who are already using the other one to have to pull in the other, but perhaps there is a creative solution ...

What might work is to check Calendar.UTCOnlyTimeZoneDatabase at application start and complain if it is set to Calendar.UTCOnlyTimeZoneDatabase, and then see if Tz or TimeZoneInfo is available and if so register those with a warning, otherwise emit an error.

Let's see if I can cook up a PR for this between periods in the hockey game :)

[dabaer]

Yup I did see that issue from kip and that was the first thing I tried. I initially thought I didn't because I didn't have it configured but then I found out Timex configures itself as the timezone database by default. I did also try installing tz and configuring it as the timezone database, and the dtstart and end was still nil

[aseigo]

Ah, the dtstart and dtend fields are indeed nil. Hum. Back into the unit test mines for me, then ...

[dabaer]

ICal.Deserialize.to_date_in_timezone doesn't take into account the value parameter and only expects a DateTime string.

I suppose the only time the %{"VALUE" => "DATE"} clause of to_date would be called is if there was no TZID specified. Perhaps we could pass the rest of the params and handle that directly in to_date_in_timezone?

EDIT: Seems to check out, if I remove the TZID param from the file, dtstart is now populated with a Date

[dabaer]

Something like 7fc9d7c ?

[aseigo]

Doing some RFC reading, in the Time Zone Identifier of RFC5545, there is this:

The "TZID" property parameter MUST NOT be applied to DATE
properties and DATE-TIME or TIME properties whose time values are
specified in UTC.

So this file is actually non-conforming, and whatever generated it is broken. If you know where it came from, perhaps giving them a heads-up would be appreciated?

In any case, ICal should still parse this brokenness, and you did find the right place indeed :) There is an even simpler fix, though: https://github.com/expothecary/ical/pull/49/changes#diff-e83d53812d93333290b9f614aaa200b5e08a6493d0b0c81a10f430b22c397199L444

If you could try that branch and confirm it works as expected for you, I will merge and make a release :)

Thanks for the report and digging into the code!

[aseigo]

"That branch" of course is #49 :)

[dabaer]

Omg it was so subtle I looked at it for a good 30 seconds before I realised what changed. Even more succinct and works great on my problem ical events.

I will try to raise them on the issue, but I bet it's a mainstream entrenched library (especially in the asp/c# ecosystem) that behaves like that for backwards compatibility reasons 😅

Thanks again, and happy to ruffle through the code anytime!

[aseigo]

New release available with the fix -> https://hex.pm/packages/ical/2.0.1

Enjoy! :)