bug#53396: 27.1; icalendar rendering should include timezone

[Antoine Beaupré]

On 2022-01-21 11:16:18, Lars Ingebrigtsen wrote:
>> 2022/1/25 13:00-14:00 Next team meeting
>>  Organizer: mailto:user@example.org
>> 
>> After:
>> 
>> 2022/1/25 13:00-0500 - 14:00-0500 Next team meeting
>>  Organizer: mailto:user@example.org
>
> That looks very confusing, I think -- I first read that as a
> mis-formatted time range from 13:00 to 05:00.  

I'm used to seeing times with a trailing offset, so I don't find this
that confusing anymore. But I know where you're coming from.

> If we want to include the time zone in the display, it shouldn't be
> appended to both the start and end times (it's unlikely that they're in
> different time zones),

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.

So I would suggest keeping both.

> 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

?

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

I had to repeatedly do the conversions (and look at the .ics source!) to
make sure it's local time. And I keep forgetting, somehow. Reading the
source code *kind* of helped, but made me frankly a little more confused
about the entire thing.

I understand this might be controversial, for people that maintain their
own agenda or work only with local times and don't have to deal with
timezones. But for people working fully remote, this makes the rendering
pretty much unusable, as I can't trust it.

How about making this configurable, maybe?

-- 
If we do not do the impossible, we shall be faced with the unthinkable.
                        - Murray Bookchin