Re: Diary icalendar tests still broken

> From: Sean Whitton <[email protected]>
> Cc: [email protected], Richard Lawrence <[email protected]>, Pip Cet
>  <[email protected]>
> Date: Fri, 31 Jul 2026 11:00:04 +0100
> 
> Richard Lawrence [31/Jul  8:19am +02] wrote:
> > The patch looks big, because it tweaks the representation of one of the
> > most widely-used data structures, but in fact it is a small change and I
> > am pleased with how easy it was to make.  I can't promise there are no
> > new bugs, but I *am* confident that this patch is strictly an
> > improvement over the code without it, and any new issues will be minor.
> >
> > --
> > Best,
> > Richard
> >
> > From 812d91be7118c1deb258466da7c6b5ace8053e93 Mon Sep 17 00:00:00 2001
> > From: Richard Lawrence <[email protected]>
> > Date: Wed, 29 Jul 2026 09:29:25 +0200
> > Subject: [PATCH] Distinguish UTC vs. UTC+0:00 times in iCalendar library
> >
> > 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.
> 
> Stefan, do I recall correctly that you originally reviewed this new
> library?  Would you be able to review this patch?
> 
> Eli, what do you think about installing this on the release branch?
> I'm wondering whether we should just disable the tests instead.
> On the other hand, the library is new in Emacs 31 and is fairly niche,
> so maybe we should go with the idea that this is a pareto improvement,
> as Richard argues.

The tests are not a critical part of the release, so I think we should
install the patch on the release branch if it improves the results in
some cases and doesn't cause any known regressions.