Closed anarcat closed 2 weeks ago
Hey @anarcat! I agree that changing the start timezone should also modify the end one. In most cases, users do indeed want the same timezone for both times, and that would save them a second search.
However, we are still thinking of keeping the end time zone selector, in this way: https://github.com/nextcloud/calendar/issues/6385#issuecomment-2401043906. I agree that it is a bit of a weird feature, but we want to be as close to the CalDAV RFC as possible in order to be compatible with other clients (https://icalendar.org/CalDAV-Access-RFC-4791/5-2-2-caldav-calendar-timezone-property.html).
Plus, there are indeed some people who fly a lot. I'm closing this seeing as I think that this answer covers everything, but feel free to re-open if you have something to add, we'd love to hear your opinions.
that looks good to me, can't we to see that in NC! :)
Steps to reproduce
Expected behavior
The end timezone should also be changed to reflect the start timezone.
Actual behaviour
In the above steps, The event now became (say) 5 hours and 30 minutes long because the end time zone didn't change, which is really confusing and error prone.
Calendar app version
5.0.1
CalDAV-clients used
N/A
Browser
Firefox ESR 128.4.0esr-1~deb12u1
Client operating system
Debian Linux
Server operating system
Debian Linux
Web server
None
Database engine version
None
PHP engine version
None
Nextcloud version
No response
Updated from an older installed version or fresh install
None
List of activated apps
No response
Nextcloud configuration
No response
Web server error log
No response
Log file
No response
Browser log
No response
Additional info
There should be a single timezone for the start/end time. I cannot fathom in what weird universe an event would start and end at different time zones, except maybe for flights, and that's a pretty narrow edge case. For those cases, it might be nice to have an option to change the end time.
I do not actually have access to the server to provide needed information on that front.
This might be covered by (but is much narrower than) #6385.