GNOME Bugzilla – Bug 795199
Add "floating time" "timezone" option for events
Last modified: 2019-04-01 11:48:31 UTC
Currently there's no way AFAICS to create a floating time event (i.e. one that is always relative to the user's currently configured time zone).
Please provide a use case. Currently this ticket offers a solution to an unknown/undescribed problem.
Scheduling individual actions relating to the person's day; co-ordination of recurring daily activity a group travelling together; marking events tied to a specific time (e.g. Armistice Day).
See also #795202 - all-day events are (sensibly) created using floating time, but the UI doesn't reflect this.
Thanks for a bug report (and bug #795202). There's a question what it does with various backends. Notably evolution-ews, whether it can handle floating times properly, not only by Evolution itself, but also by Outlook/OWA. It requires some testing and investigation. That it works for All-day doesn't necessarily mean it will work for generic events the same.
> There's a question what it does with various backends. CalDAV: * interprets as current time zone when displaying - correct * populates time zone field with specific current time zone when editing - incorrect * writes out specific current time zone even when editing unrelated fields - correct per editing UI, incorrect overall So there's already a bug here - Evo incorrectly handles editing of existing floating time events. I'd suggest that allowing the specifying of floating time in the UI is actually the only sane way of handling that bug - otherwise the UI would need to be changed anyway to disable editing of the event time entirely (plus explanation somehow).
(In reply to Stephen from comment #5) > > There's a question what it does with various backends. > > CalDAV: I didn't mean what it does in evolution as such, I meant whether the server the backend talks to can handle it properly or better whether the backend can transform the data in the correct way.
I propose declining this task. IMO offering such functionality would be confusing, error-prone, and creates more harm than good. Plus likely ifdef'ing a good number of lines of code for each and every calendar backend out there. (In reply to Stephen from comment #2) > Scheduling individual actions relating to the person's day; Everybody is free to schedule an individual action themselves, or one person is free to schedule individual actions in each person's timezone. > co-ordination of recurring daily activity a group travelling together I don't see how that is related to the proposal in this task. > marking events tied to a specific time (e.g. Armistice Day). I don't see how that is related to the proposal in this task.
> I meant whether the server the backend talks to can handle it properly Specific crippled server/backend protocol implementations shouldn't cripple the client for all users in turn though! At least iCal/CalDAV (i.e. actual open standards!) fully cover floating time. > or better whether the backend can transform the data in the correct way. This would be better ;) > IMO offering such functionality would be confusing Why? > error-prone Why? > creates more harm than good Why?? > Everybody is free to schedule an individual action themselves, or one person is free to schedule individual actions in each person's timezone. No, I meant an individual scheduling a recurring event for e.g. "11 a.m. every Tuesday", that remains at that time of day even when they travel to a different time zone. That example was not about a multi-person event. >> co-ordination of recurring daily activity a group travelling together > > I don't see how that is related to the proposal in this task. Same as above, but as a group event when the group is travelling together - e.g. "cruise ship leaves port at 10 p.m. every day". >> marking events tied to a specific time (e.g. Armistice Day). > > I don't see how that is related to the proposal in this task. It's marked by a minute's silence at 11 a.m. wherever you are, on a specific day. Other examples might be prayer times, fasting times etc. for the religious, which relate to a specific time of day unrelated to a specific time zone. > Evo incorrectly handles editing of existing floating time events. This bug exists regardless, and a fix would require handling of floating time in the UI, in underlying Evo code and in backend(s) anyway.
(In reply to Stephen from comment #8) > > error-prone > > Why? If you have several people attending the very same appointment which is displayed at different times in different calendars depending on each user's time zone settings and there is a location attached to that appointment (e.g. a video conference URL), people will miss each other.
> If you have several people attending the very same appointment which is displayed at different times in different calendars depending on each user's time zone settings and there is a location attached to that appointment (e.g. a video conference URL), people will miss each other. You are effectively saying "if someone manually and specifically changes the time zone setting to floating time when it should not be set to floating time, it will not be correct." You could also say something similar for someone deliberately setting the time zone to "New York" when it should be "London" - "then it will be set to the wrong time". That is not an argument against geographical time zones either.
I'm effectively saying that if you set no timezone at all, people taking place in the same event will miss each other.
> I'm effectively saying that if you set no timezone at all, people taking place in the same event will miss each other. The default should be the current time zone, not floating time, so this would not be a problem.
This had been filled also in [1], thus I close this in favor of the new bug. Please see it for any further updates. [1] https://gitlab.gnome.org/GNOME/evolution/issues/385