GNU bug report logs - #53396
27.1; icalendar rendering should include timezone

Previous Next

Full log

Message #14 received at 53396 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Antoine Beaupré <anarcat <at> debian.org>
Cc: 53396 <at> debbugs.gnu.org
Subject: Re: bug#53396: 27.1; icalendar rendering should include timezone
Date: Sat, 22 Jan 2022 12:29:47 +0100

Antoine Beaupré <anarcat <at> debian.org> writes:

> True, but which one do you pick? This is not only possible in theory:
> it's absolutely possible someone messes that up and generates a ics file
> that has different timezones for start and end. I've seen this happen in
> Nextcloud, which makes you pick a timezone for *both* times,
> manually. People frequently mess it up.

It's really unusual, though, and making the common case harder to read
to cover an odd edge case isn't ideal.  If the time zones are indeed
different, then they should be displayed, but if not, not.

>> and it should be formatted in a different, less
>> ambiguous way, but I'm not sure how.
>
> Maybe using a different separator? Say:
>
>  2022/1/25 13:00-0500 to 14:00-0500 Next team meeting
>
> or:
>
>  2022/1/25 13:00-0500 @ 14:00-0500 Next team meeting
>
> ?

It's not really an improvement.  Perhaps the time zone could be in a
parentheses somewhere, and explicitly say that it's a time zone.

Or a tooltip, and then we could list both the numeric and the symbolic
name for the timezone.

>> And if it's in the local time zone, it probably shouldn't be included at
>> all.
>
> Well that's exactly the problem here. Local time might be assumed
> sometimes, but in certain remote work environment, it's a serious
> mistake, because it's really ambiguous.

That's true, and having it be explicit helps making sure.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.