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

Previous Next

Full log

View this message in rfc822 format

From: Antoine Beaupré <anarcat <at> debian.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 53396 <at> debbugs.gnu.org
Subject: bug#53396: 27.1; icalendar rendering should include timezone
Date: Sun, 23 Jan 2022 16:04:25 -0500

On 2022-01-22 12:29:47, Lars Ingebrigtsen wrote:
> 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.

But then you end up with the same usability problem, in that case. I
want to address that degenerate case.

>>> 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.

A time followed by a negative/positive number is the standard way (ISO)
to show the timezone. Not sure parenthesis would be much clearer, it
would carry potentially even more ambiguity.

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

That is far beyond what i can provide in terms of Emacs programming. :p

>>> 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.

I'm happy to see my patch adapted somehow, if people have the energy for
that.

Couldn't that display be at least customize'able?

-- 
To punish me for my contempt for authority, fate made me an authority myself.
                       - Albert Einstein

Previous Next

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