| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
format-timestamp built its date from the start and took only the hour and
minute from the end, so the end date was thrown away. A conference running Jul
20 09:00 to Jul 23 17:00 produced <2026-07-20 Mon 09:00-17:00>, byte for byte
the same timestamp as a same-day meeting, and the agenda showed it on the first
day only. All-day spans collapsed the same way, to a bare <2026-07-20 Mon>.
An event whose last day is later than its start now renders as an org range,
<start>--<end>, which org parses as an active-range and shows on every day it
covers.
DTEND is the non-inclusive end of the event (RFC 5545 3.6.1), so an all-day
event's last day is DTEND-1. Getting that backwards would have been worse than
the bug: a one-day all-day event carries DTEND = start+1, so a naive range
would turn every single all-day event into a two-day one. The decrement only
applies when both ends are date-only. A date-only start with a timed end is
malformed, and treating it as all-day would put the last day before the start
and emit a backwards range. That case falls through to the same-day form, as
before.
I split out format-stamp and format-hhmm so both halves of a range and the
compact same-day form build from one place.
Same-day events are unchanged, pinned by two tests: the compact HH:MM-HH:MM
form, and a single all-day event staying a single stamp.
One unrelated bug stays open. A timed event with no DTEND renders as <date> and
drops its time, so a 09:00 meeting reads as all-day. I left it alone.
|
|
|
Covers core parsing (parse-ics-datetime, parse-timestamp, format-timestamp,
split-events, parse-event), date utilities (add-months, add-days,
weekday-to-number, date-weekday, event-start-time), and timezone
(format-timezone-offset, convert-utc-to-local, localize-parsed-datetime).
|
