Time is a complicated concept and it's hard to implement properly in computers.

This page aims at documenting some bits that we have to deal with in TPA.

Daylight saving handling

For some reason, anarcat ended up with the role of "time lord" which consists of sending hilarious reminders describing the chaos that, bi-yearly, we inflict upon ourselves by going through the daylight saving time change routine.

This used to be done as a one-off, but people really like those announcements, so we're trying to make those systematic.

For that purpose, a calendar was created in Nextcloud. First attempts at creating the calendar by hand through the web interface failed. It's unclear why: events would disappear, the end date would shift by a day. I suspect Nextcloud has lots of issues dealing with the uncertain time during which daylight savings occur, particularly when managing events.

So a calendar was crafted, by hand, using a text editor, and stored in time/dst.ics. It was imported in Nextcloud under the Daylight saving times calendar, but perhaps it would be best to add it as a web calendar. Unfortunately, that might not make it visible (does it?) to everyone, so it seems better that way. The calendar was shared with TPI.

Future changes to the calendar will be problematic: perhaps NC will deal with duplicate events and a new ICS can just be imported as is?

The following documentation was consulted to figure things out:

• iCalendar on Wikipedia
• RFC5545 ("Internet Calendaring and Scheduling Core Object Specification (iCalendar)"), which is massive, so I also used the icalendar.org HTML version in particular:
  • Recurrence rules and the rule generator which didn't actually cover the cases we needed ("last Sunday of the month")
  • 3.3.5 Date time
  • 3.8.4.7. Unique Identifier
• the iCalendar.org validator must be used before uploading new files, it's easy to make mistakes

Curses found

Doing this research showed a number of cursed knowledge in the iCal specification:

• if you specify a timezone to an event, you need to ship the entire timezone data inside the .ICS file, including offsets, daylight savings, etc. this effectively makes any calendar file created with a local time eventually outdated if time zone rules change for that zone (and they do), see 3.8.3.1. Time Zone Identifier and 3.6.5. Time Zone Component
• blank lines are not allowed in ICS files, it would make it too readable
• events can have SUMMARY, DESCRIPTION and COMMENT fields, the latter two which look strikingly similar and 3.8.1.4. Comment
• alarms are defined using ISO8601 durations which are actually not defined in a IETF standard, making iCal not fully referenced inside IETF documents
• events MUST have a 3.8.7.2. Date-Time Stamp (DTSTAMP) field that is the "date and time that the instance of the iCalendar object was created" or "last revised" that may differ (or not!) from 3.8.7.1. Date-Time Created (CREATED) and 3.8.7.3. Last Modified (LAST-MODIFIED) depending on the 3.7.2. Method (METHOD), we've elected to use only DTSTAMP since it's mandatory (and the others don't seem to be)