Re: Diary icalendar tests still broken

Stefan Monnier via "Emacs development discussions."
<[email protected]> writes:

>> This fixes a bug discussed on emacs-devel; see the thread at
>> https://https://lists.gnu.org/archive/html/emacs-devel/2026-07/msg00445.html
>>
>> The issue was that the library did not distinguish between UTC time and
>> times that have an offset of 0 but are not in the UTC time zone,
>> e.g. standard times in Europe/London or Europe/Dublin.  This led to test
>> failures on systems in these time zones.  This fix represents true UTC
>> times by inserting the special value `t' in the zone slot of a decoded
>> time at parse time (which `encode-time' already handles correctly).
>> This distinguishes them from decoded times with an offset of 0 seconds.
>
> Could you explain why we care about the difference between "0 offset"
> and "UTC"?
>
> I understand that we care about the difference between UTC and timezones
> which happen to currently have a 0 offset, since those same timezones
> may have a non-zero offset at some other moment of the year, but for
> a given `decoded-time` object I don't see why it matters (if it did, I'd
> expect that we'd want to remember the actual timezone rather than merely
> the offset). 

Right, and remembering the timezone is exactly the source of the test
failures in question here.

iCalendar properties record the timezone in a "TZID" parameter separate
from the time value (which is parsed as a decoded time).  The standard
disallows this parameter when the time value is in UTC, so there is a
validation function in the library that verifies that when the TZID
parameter is present, the associated time value is not a UTC time.  The
tests were failing on systems in these time zones because this validation
function saw a 0 offset in a property with a TZID like "Europe/London",
and thought, "That's a UTC time with a TZID, that's not allowed," and
signaled a validation error.  So distinguishing these cases (i.e., more
narrowly defining what counts as a decoded time "in UTC") is the way to
keep this validation function happy in those time zones.

-- 
Best,
Richard