NAME
ratrun.ics
—
iCalendar emulation for
ratrun
SYNOPSIS
$
head
-n
1
~/.ratrun/an-event[.ics
]
BEGIN:VCALENDAR
DESCRIPTION
Internet Calendaring and Scheduling Core Object Specification (iCalendar), also commonly known by its prescribed extension .ics and much less commonly as VCALENDAR, is ubiquitously used for that purpose, and primarily distributed as text/calendar parts.
To that end, files in this format may be freely used as ratrun(8) events in ~/.ratrun/.
iCal is complicated and ratrun
is not, so
support is only emulated, by using
DTSTART
- as the event time (in the proper
TZID
time-zone), SUMMARY
- in the
Subject:
header, DESCRIPTION
- if any, as the notification mail body, and
TRIGGER
s- if any, to override the default reminders.
FILES
- /usr/share/zoneinfo/
TZID
s are validated to exist here before being used.
SEE ALSO
rat(1),
rerat.ics(7) – its X-RATSTART
keys are
also understood,
ratrun(8)
🐀
STANDARDS
Unrelatedly, this emulator is expected to be compatible with most common commercial calendar front-ends and probably all sane ones; it was tested against Microsoft Outlook (2019), Microsoft Teams, aCalendar, Evolution (GNOME™), and Google Calendar™, with largely favourable results.
BUGS
Besides, of course, not actually parsing iCal, in no particular order:
- only single-event files produce favourable results; §3.6. Calendar Components, final para. states: "a complex iCalendar object that is used to capture a complete snapshot of the contents of a calendar is possible. More commonly, an iCalendar object will consist of just a single […] calendar component.", and most CUAs won't even let you export more than one at a time (the one multi-event object in the test corpus (so far!) comes from a ticket distribution system, and nothing is lost there),
- recurring of events (
RRULE
) isn't handled at all, - positive and absolute
VALARM
TRIGGER
s are ignored, all are assumed to be relative toDTSTART
, - all other
VALARM
fields are ignored (this is a feature actually), - iCal has an opulent system for specifying time-zones. We consider
X-WR-TIMEZONE
equivalent, - §3.2.19. Time Zone Identifier, Note kindly recommends
"Implementers may want to use the naming conventions defined in
existing time zone specifications such as the public-domain TZ
database", and, indeed, non-Microsoft products largely do, if they
don't just spec a UTC time. To support the rest, with decent hit-chance,
these are tried, in order, with the first extant used:
- the
TZID
itself, - the same with "Standard" removed, or
- 2. or 1., but only the upper-case characters (reduced to acronym);
- the
- printf(1)
%b
is used to expand \ escapes.