Calendar: Let user decide their timezone

[georgehrke]

There are quite a few people having issues with our automatic timezone detection: https://github.com/nextcloud/calendar/issues/496

Furthermore there are scenarios where you want to see the calendar in a different timezone.
Let's say you are on a trip in New York and want to see your calendar for next week, where you gonna be in Germany again, then you will want to see the appointments for next week in the german timezone. Therefore a user should be able to overwrite the timezone setting.

Additionally, users accessing the public sharing site, should also be offered a timezone dropdown.

Where should we place the timezone dropdown?
Settings in calendar or personal settings?
(I was thinking about upper right corner for public sharing site)

Default should always be set to automatic detection.

cc @jancborchardt @leonklingele-work @tcitworld

[tcitworld]

There are quite a few people having issues with our automatic timezone detection: #496

Also got a few issues for my users who didn't report here.

I think a timezone setting could go with a new personal setting in server (just like the locale setting - maybe hidden by default - let's talk of this in server ?)
For the public view, I guess your solution is fine.

[leonklingele-work]

https://github.com/nextcloud/server/pull/6363 brings support to extend the "Personal Settings" page from 3rd party apps in case the timezone selector will not land in _server_ directly.

[jancborchardt]

Bottom left Calendar setting. That also works on the public page (not top right).

[georgehrke]

I think this should actually be a Nextcloud wide setting because the Tasks app (and maybe others) will need it too.

[jancborchardt]

Ok, sounds good.

[georgehrke]

There is actually an issue with making it a Nextcloud-wide setting. :/

If we make it a Nextcloud-wide setting, we will most certainly make that value available via some PHP API. But if it's accessible via PHP, we lose the ability to automatically determine the timezone using jstz.

Making it available only via some JS API feels weird because that's usually not how we do things and some developers will probably end up reading the value straight from the database ...

Any thoughts?

[jancborchardt]

Since we have no implementation at all right now, let’s tackle it in a way which solves it ideally from a UX point of view in the scenarios we need to cover. :)