Canvas Quirks Encyclopedia

Floating times can put deadlines on the wrong day

Some calendar-feed timestamps carry no timezone at all — DTSTART:20260708T235900, no Z, no TZID. RFC 5545 calls this floating local time and makes resolving it the reading app's responsibility. An app that guesses UTC shifts the event by your whole UTC offset — in US Central, enough to move an 11:59 PM deadline onto the next day. In building Margin's feed parser we resolve floating times in the reader's own browser timezone, which is what the spec intends.

What this looks like from a student's side

You subscribe a calendar app to your assignment feed, and the dates come out slightly wrong in a way that is easy to dismiss. A deadline you know is Wednesday shows on Thursday. Late-evening due times — the 11:59 PM ones — are the worst case, because they sit close enough to midnight that even a small offset carries them across the date line. The event is not missing and nothing errors; it is sorted into the wrong day, so it does not appear in the list you check tonight.

The size of the shift is your UTC offset, so readers far from UTC see the largest effect, and someone in London may never notice at all — which is part of why this goes unreported.

Why the format allows it

RFC 5545 §3.3.5 defines three forms of date-time value. One ends in Z and is fixed to UTC. One carries a TZID parameter naming a timezone. The third carries neither, and the spec's own term for it is floating: it is not tied to any timezone, and it is meant to be interpreted in the local time of wherever the event is being read.

That is a deliberate feature, not a malformed file. Floating time is how you express "9:00 AM, whatever 9:00 AM means where you are." The problem is that it hands the decision to the consuming application, and an application that quietly assumes UTC for anything without a Z produces a silent, systematic offset rather than an error.

How to tell whether this is what is happening to you

  1. Look for a pattern, not a one-off. A single wrong date is usually a data-entry issue. Every date in one feed shifted by the same amount, in the same direction, points at timezone handling.
  2. Compare the wrong time against the right one. If every item in the feed is off by the same number of hours and that number equals your UTC offset, timezone handling is the cause — items near midnight are the ones that cross into another date.
  3. Read the raw file. Save the .ics and open it in a text editor. Find a DTSTART line for an assignment you can verify. If it ends in Z or carries ;TZID=, then this quirk is probably not what you are looking at. If it is a bare YYYYMMDDTHHMMSS, it is floating, and how it renders is entirely up to the app showing it to you.

What you can do about it

Evidence