Change option's time handling and add timezones

[dartcafe]

• switch timestamp to ISO date
  may be reverted
• switch duraton in seconds to ISO Interval
• Allow to change default timezone per poll
• allow to select the preferred timezone for participants

closes #4045
closes #3700
closes #2368
closes #2851
closes #3699

Timezone selection is only available in date polls and if the polls's original timezone does NOT match the local timezone.

set timezone (poll configuration)	select original timezone set by owner	select visitor's local timezone	add option

To dos:

• Fix design issues
• Fix layout issues with changing view ports
• Code tidy
• Backend tests
• migration of options and votes

Affects options and votes:
Usage of timestamps have been replaced by DateTimeImmutable.
Duration in seconds has been replaced by DateInterval.

To avoid migrations now, the db will still receive timestamps and duration values in seconds, but also ISO formatted strings representing the option's timestamp and duration. API got extended by the ISO values.

ISO always values get precedence over their numeric sibling, either from the values read from the database or when set using the API.

[andreas-1107]

This is definitely a big improvement, thank you! One comment:

I would recommend that the guest/visitor could choose to view it in the poll creator's / original timezone. This will remove confusion as to what was the intent of the poll creator, which I think is the main issue today.

The behaviour seems to be the opposite in the screenshots. I understand New York is the poll creator's time zone, Berlin is the guest's time zone. I would suggest to switch the behaviour so that if I, as guest, click "original time zone" I see the poll as the creator made it (e.g. as if I am in New York). So I would see "23 January" only when selecting "original time zone". And if I switch to Berlin, I would see the Berlin times.

A different note on UX, perhaps for next change:

Other tools, for example Doodle, just ignores the time zone for full day events. If I create an all-day event in UTC 0 (Iceland), then it does not matter what time zone I select as a guest, it always displays the full day event as if I was in Iceland. Check here: https://doodle.com/group-poll/participate/e50qBgXd/vote

But time specific events are moved to the corresponding date. Screenshots below.

Thanks again for the good work 👍

[PhrozenByte]

Great work, thanks for implementing this ❤️

I haven't really used polls for quite some time, but since I participated in the discussions intensively back then I felt the obligation to at least give it a try. The PR code runs without any issue (but I didn't do a code review), here are a few more suggestions (which can also be ignored since I'm basically a non-user):

• For all day events polls IMHO shouldn't even store time and timezone, but just the date (which should be possible with datetime strings now, e.g., iso_timestamp = "2026-01-13" and iso_duration = "", or something like that, but I didn't check the code, just the database contents). For all-day events polls can't reasonably assume that the user truly wanted to create a 00:00-24:00 event, see Allow ignoring timezone for date only polls #2368 (comment). polls should then just show the event with a date, but without time, which is also unaffected by whatever timezone the user selects
• Nevertheless it should still be possible to explicitly create 00:00-24:00 events (i.e., by creating an event that starts at 00:00 and takes 24 hours or 1 day, e.g., iso_timestamp = "2026-01-13T00:00:00.000+01:00" and iso_duration = "P1D")
• I'm not sure whether poll_option_text is used for anything (seems like it's used when exporting a poll, but I'm not sure), but its datetime strings seem to always use UTC (or the server's timezone?), not the poll's timezone
• In general, polls IMHO should use the poll's timezone by default (basically just pre-select that in the timezone notice; the notice is hard to miss IMO)
• When creating new events as a poll owner, polls doesn't use the timezone selected in the timezone notice, but always the user's timezone (i.e., if I select the poll's timezone in the timezone notice and create new events, it should use the poll's timezone; if I select my local timezone instead, it should use my local timezone for new events)

[dartcafe]

@andreas-1107

So I would see "23 January" only when selecting "original time zone". And if I switch to Berlin, I would see the Berlin times.

That is, how it works. In the example, New York ist the poll's timezone, defined by the owner. Berlin is the visitors (local) timezone. The pictures may be confusing due to the shifted dates of the "original" timezone.

I simply did not adjust the dates so that they match in a plausible way.

Other tools, for example Doodle, just ignores the time zone for full day events. If I create an all-day event in UTC 0 (Iceland), then it does not matter what time zone I select as a guest, it always displays the full day event as if I was in Iceland.

I was thinking about it but it may have some issues, if the visitor sits far away (i.e. 12 timezones away). If the date is i.e. 2026-01-18, what does that mean for the visitor? Which day may be meant from his perspective. 2026-01-17, 2026-01-18 or 2026-01-19, depending of the direction (+12 or -12 hours)? This may be more confusing.

Most of the times the polls will show no timezone information, because owner and participants will reside within the same timezone.

I believe, that selecting the timezone in case of different timezones between visitor and owner is the most transparent information.

And to be honest, adding options with a particular timezone is still not done yet.

[dartcafe]

@PhrozenByte

I haven't really used polls for quite some time, but since I participated in the discussions intensively back then I felt the obligation to at least give it a try. The PR code runs without any issue

🙏 Thanks for taking the time for testing. Be aware, that adding options inside a particulair timezone is still WIP.

For all day events polls IMHO shouldn't even store time and timezone, but just the date (which should be possible with datetime strings now, e.g., iso_timestamp = "2026-01-13" and iso_duration = ""

Yes I am thinking about something like this, and try to fiddle out a good and working method. What keeps me from this for the moment is the migration. We have to be very very careful about it to avoid breaking existing polls. Currently the backend is not fully clean and needs a lot of polish. Fallbacks are needed as removing obsolete code.

Nevertheless it should still be possible to explicitly create 00:00-24:00 events

I guess this will be possible out of the box after the PR is finished.

I'm not sure whether poll_option_text

I stores the options for a textpoll and a readable ISO like interval. Additionally it is a key for indices and for matching votes to an option. And yes, it is UTC here.

In general, polls IMHO should use the poll's timezone by default (basically just pre-select that in the timezone notice; the notice is hard to miss IMO)

I plan to make this optional, so a poll owner can decide, which timezone should be used as default for a visitor.

When creating new events as a poll owner, polls doesn't use the timezone selected in the timezone notice, but always the user's timezone (i.e., if I select the poll's timezone in the timezone notice and create new events, it should use the poll's timezone; if I select my local timezone instead, it should use my local timezone for new events)

Yes. Currently WIP, see comments before. The UI needs some tries to make it usable. In the end, both timezones will be displayed and also the timezone for the date-time selector should be selectable (Proposals of visitors in mind).

[dartcafe]

@PhrozenByte @andreas-1107

Thank you guys for this immediate responses. Helps a lot.

[andreas-1107]

Other tools, for example Doodle, just ignores the time zone for full day events. If I create an all-day event in UTC 0 (Iceland), then it does not matter what time zone I select as a guest, it always displays the full day event as if I was in Iceland.

I was thinking about it but it may have some issues, if the visitor sits far away (i.e. 12 timezones away). If the date is i.e. 2026-01-18, what does that mean for the visitor? Which day may be meant from his perspective. 2026-01-17, 2026-01-18 or 2026-01-19, depending of the direction (+12 or -12 hours)? This may be more confusing.

Most of the times the polls will show no timezone information, because owner and participants will reside within the same timezone.

I believe, that selecting the timezone in case of different timezones between visitor and owner is the most transparent information.

I understand what you mean, and I think the case of +12 / -12 hours is sort of an edge case, as we tend to have meetings more rarely with people who are further away - and +/- 12h is always the furthest away it's possible to get :)

I believe the full-day event is used most often when time zone differences are smaller (e.g. 1h or 2h), but even 1h difference in time zone causes confusion with the current UX as the event then appears to be spanning multiple dates.

So I think this is why Doodle have opted for keeping full-day events without time, and letting the user figure out which date is referred to using the context of the poll if there is any doubt (who created it, for example). As in the absolute majority of the cases, it will be obvious to the user what date is meant.

My 2 cents on this point is to allow the potential confusion of the +/- 12h time difference and prioritise the more common user experience of scheduling full-day events.

[dartcafe]

The timezone difference between Moscow and New York counts 8 hours. Now imagine Trump wants to meet Putin and they miss each other because of misinterpreting the day. 😉

I think I understand the issue completely. I am absolutely sure, the majority of meeting organization happens within the same timezone. But I want to make sure, this works under any circumstances.

This means for a whole day event:

• either we mark ist as a 24h span and accept the shifts and allow to switch the timezone
• or we just point to the date without any time information but have to add the timezone, where day fits. And of course we allow changing timezones also.

The first solution will fit into the current scheme of Polls, how it handles dates and times. And it fits to exiting polls and just extends but does not change them. The second one can be a further optimization, but needs more time and coding and testing and migration.

BTW: With the planned option of setting the poll owner's timezone as the default should avoid the confusion too at first hand.

And also thanks for participation in the discussion and adding your feedback. Valuable!!!

[andreas-1107]

Ah, thank you for pointing out that the poll creator's time zone will be the default one (and not the visitor's browser for example). That will resolve the current UX confusion I think, as (I believe) most people won't change the time zone for polls with only full day events. 👍👍

[dartcafe]

Adding options to a poll with flexible timezones was pushed.
To dos are in the first comment.

[dartcafe]

This took more time than expected, but I hope finally it is done.

• Timezones are applied as I expected (in my tests).
• Internally date and time information are now handled by DateTimeImmutable class instead of a timestamp and
• durations are no more defined by seconds but by a time interval using ISO strings by the back-end.
• Timestamps and duration in seconds are still supported to avoid expensive migrations for the database and for the API.
• The API (option endpoints) got an extension, so that ISO strings are also supported.

This had more side effects and caveats than I was ready for. 😬

If anyone will give the beta a try and wants to roll back afterwards, just install the last release and

• delete the columns iso_duration and
• iso_timestamp from oc_polls_options and
• delete the migration entry from oc_migrations: app: polls, version: 090000Date20260302211900

So @andreas-1107 and @PhrozenByte or anyone else: If you could give it a try and smoke test the beta (from the appstore or from the releases page) ...

v9.0.0-beta.2 will be out today.

Since Nextcloud 31 is out of maintenance, this feature will mark the 9.0.0 milestone and Support of PHP 8.1 is also dropped. Although not explicitly tested, PHP 8.5 should work, too.

This PR will get merged soon, so please report any issues in a new issue.

[PhrozenByte]

Great work, thanks @dartcafe! ❤️

I tested with the current PR (fresh install from sources) and noticed the following 8 things (some suggestions, some bugs, and one note). I wasn't sure how to report this, so I decided to tell it like a step-by-step reproducer, I hope you can follow what I was doing:

---

Step 1

Let's assume I'm in "Europe/Berlin" and want to create a poll with "America/New York". I thus select "America/New York" as the poll's default timezone first. I then open the options modal. The defaults are: "Whole day" enabled, "2026-03-03" (i.e., today), timezone "Europe/Berlin" and a duration of "0 days". polls previews the following:

1. Suggestion: I'd recommend selecting the poll's default timezone by default here instead of the user's timezone.

2. Suggestion: I'd recommend using "1 days" as default duration.

Adding that option creates a 2026-03-02T23:00:00+00:00 option with 1D duration.

3. Bug: Why does the default "0 days" duration create an option with 1D duration? If I see "0 days", I expect polls to create an option without any time information.

---

Step 2

I reload the page and open the options modal again, but select "2026-03-04" (i.e., tomorrow) instead. I additionally choose timezone "America/New York" and a "1 day" duration, so polls previews the following:

Adding that option creates a 2026-03-04T05:00:00+00:00 option with 1D duration. This is perfectly fine.

---

Step 3

I reload the page and open the options modal again. Default timezone is "Europe/Berlin" again. I select "2025-03-05" and disable "Whole day". The time defaults to "18:15" (which is the current local time). I also keep the default "0 days" duration.

4. Suggestion: In addition to the first suggestion above, polls could remember (just in the browser's local storage, per poll) what timezone was used last. The options modal should then use that timezone again instead of the default.

Adding that option creates a 2026-03-05T17:15:00+00:00 option with a null duration.

5. Note: I'd say that's expected since "0 days" was the default duration, even though I recommend changing that to "1 day", or maybe "1 hour" when the "Whole day" option is disabled. However, note that "0 days" now behaves different than before: With "Whole day" enabled it is interpreted like "1 days", but with "Whole day" disabled it's interpreted like the literal "0 days".

6. Bug: This just added option isn't displayed properly, simply no option text is shown:

Modal	Poll

---

Step 4

I reload the page and open the options modal again. I select "2026-03-06" and timezone "America/New York". I disable "Whole day", the time now defaults to "00:30". I keep the default "0 days" duration. However, the preview was totally unexpected and super confusing at first:

7. Bug: Why is the default time "00:30"? It's 18:30 in my local "Europe/Berlin" timezone, which equals 12:30 in the selected "America/New York" timezone. The issue might be related to the following:

8. Bug: polls still uses my local "Europe/Berlin" timezone to interpret the time. This results in pools previewing "2026-03-06 00:30" for "Europe/Berlin", equalling "2026-03-05 18:30" for "America/New York". It should be "2026-03-06 00:30" for "America/New York" instead, which equals "2026-03-06 06:30" in "Europe/Berlin".

Adding that option creates a 2026-03-05T23:30:00+00:00 option with a null duration. Note 5 and bug 6 apply again.

---

Step 5

I reload the page and open the options modal again. I select "2026-03-07" and timezone "America/New York". I disable "Whole day", manually enter a time of "12:00" and select a "1 hour" duration. Naturally the same issues as in step 4 apply:

Adding that option creates a 2026-03-08T11:00:00+00:00 option with a 1H duration. Besides bugs 7 and 8 I think that's correct.

---

Other notes

composer.json specifies a dev dependency of "nextcloud/ocp": "dev-stable30". I forgot to report that last time and just happen to remember again. It didn't cause any issues now because I didn't install the dev dependencies this time. Last time I did and it conflicted with my local Nextcloud 32. This is just a heads up. I'm not sure whether this dev dependency is actually needed (no need to explain, I don't need to know), but if it is, I assume that it at least needs to be updated.

[dartcafe]

Wow. Thanks for this detailed report.

Step 1

Zero day duration

Selecting a day with a zero duration is equal to a one day duration, if "whole day" is set. Both are interpreted as one day schedule, beginning at 00:00 and lasting until 24:00 (or better 23:59). This is manly to keep backwards compatibility and maybe subject of later change.

Selected timezone

There is only one parameter which selects the timezone ("own timezone" or "poll's timezone") and is stored in the session information. The reason, why you where faced with the local timezone is, because the initial setting is "use own timezone". If you change it in the dialog, the display setting for the poll is changed as well, assuming that the user prefers this timezone.

On reload, the setting will get reset to the default "own timezone" for the whole app. Polls does not store any information in the browser store and probably never will. Of course we could store the last setting in the users profile settings on every change. In this way we can keep the setting alive, even on reloads.

If you think this would be a solution, please open a new issue for that, because this will not be changed now.

[dartcafe]

Step 3

Zero day|month|hours|...

As stated above, this does not select "whole day", so a zero duration means a single moment in time and therefore this option actually has no duration in contrast to the term "whole day" which represents a span by definition.

but with "Whole day" disabled it's interpreted like the literal "0 days".

It is literally zero duration, no matter, which unit is selected.

The missing text has to be a bug indeed. I will check that!

[dartcafe]

Step 4 and 5

timezone mismatch

Damn, I had this on time but could not reproduce that. I thought, I did not look correctly or it was because of the dev environment.

Here the timezone seems not to be correctly applied to the display. The main information should show the chosen timezone. The other timezone is added as information. In you screenshot it is displayed the wrong way.

Have to check and fix this.

[dartcafe]

composer.json specifies a dev dependency of "nextcloud/ocp": "dev-stable30"

That's only relevant for the dev environment, but indeed outdated, have to refresh that. As well as bringing back PHP 8.1 as supported version.

[dartcafe]

Again, thanks for the support.
What is more important: Did you observe any issues with existing polls? Any exceptions thrown?

[PhrozenByte]

Step 1, Suggestion 2 and Bug 3, titled "zero day duration"

Selecting a day with a zero duration is equal to a one day duration, if "whole day" is set. Both are interpreted as one day schedule, beginning at 00:00 and lasting until 24:00 (or better 23:59). This is manly to keep backwards compatibility and maybe subject of later change.

How do I create a option without any time information then? Because if I disable "Whole day" and choose "00:00" with a zero duration, it still points to that moment in time and thus still yields a different time in other timezones:

IMHO there should be a way to create a option without any time information, i.e., a option that yields e.g. "2026-03-08" without time no matter the timezone. I'd expect this precisely from selecting "Whole day" with a "0 days" duration. I guess it should end up as iso_timestamp = 2026-03-08 (i.e., no time information) and iso_duration = null in the database then.

Just to make this clear: IMHO the default duration shouldn't be "0 days", but "1 days" with "Whole day" enabled, and "1 hours" with "Whole day" disabled. So, this won't be the default behaviour. Users would need to specifically create it that way, so there shouldn't be any backwards compatibility issues.

Step 3, Suggestion 4, titled "selected timezone"

There is only one parameter which selects the timezone ("own timezone" or "poll's timezone") and is stored in the session information. The reason, why you where faced with the local timezone is, because the initial setting is "use own timezone". If you change it in the dialog, the display setting for the poll is changed as well, assuming that the user prefers this timezone.

On reload, the setting will get reset to the default "own timezone" for the whole app. Polls does not store any information in the browser store and probably never will. Of course we could store the last setting in the users profile settings on every change. In this way we can keep the setting alive, even on reloads.

If you think this would be a solution, please open a new issue for that, because this will not be changed now.

I see, thanks for the explanation. Will think about that and possibly create a new issue 👍

Everything else

What is more important: Did you observe any issues with existing polls? Any exceptions thrown?

Unfortunately I can't say anything about that, because we don't use polls in production anymore (that's not polls fault, we just don't conduct many polls anymore 😄). I just feel somewhat obligated to test what I can, after having voted so strongly for this feature in the past. Anything else wouldn't be fair to you, in my opinion... So, don't feel obligated to implement anything of what I've just suggested, you can absolutely disregard it, no hard feelings at all then.

Again, thanks for the support.

You're very welcome, thanks again for your great work! ❤️

Let me know as soon as I shall do a final round of testing, will do that then.

[dartcafe]

How do I create a option without any time information then? Because if I disable "Whole day" and choose "00:00" with a zero duration

Yes. That's the week point in this. But this has been before and therefore will sty for the moment. Solving every edge case now will complicate things and delay the release. As I said in another Thread: This subject of change later.

Just to make this clear: IMHO the default duration shouldn't be "0 days", but "1 days" with "Whole day" enabled, and "1 hours" with "Whole day" disabled.

This also. With the current logic the value will be change, from zero to 1, is someone activates the "whole day" option. And the 1 will stay even if the user switches back.

This is a minor UX issue, which will be solved separately as well as the whole day issue.

The main focus is not to alter existing polls. The changes can affect the outcome of existing polls. And this was tough enough.

[PhrozenByte]

Yes. That's the week point in this. But this has been before and therefore will sty for the moment. Solving every edge case now will complicate things and delay the release. As I said in another Thread: This subject of change later.

Alright, fair enough, totally up to you, as I said. I just want to recommend removing "Closes #2368" from the list of issues this PR closes then - that's the existing issue tracking that particular feature 👍

With the current logic the value will be change, from zero to 1, is someone activates the "whole day" option. And the 1 will stay even if the user switches back. This is a minor UX issue, which will be solved separately as well as the whole day issue. The main focus is not to alter existing polls. The changes can affect the outcome of existing polls.

I'm not sure whether we're talking about the same thing here 🙈 😅

I'm really just talking about the UI here, not the backend. Because, in my tests, if I open the options modal, the pre-selected default duration is "0 days". If I now disable "Whole day", it stays at "0 days". If I enable "Whole day" again, it still is "0 days".

What I'm suggesting is just that instead of pre-selecting "0 days" in the UI, it should pre-select "1 days" by default. If an user then disables "Whole day", that default "1 days" should automatically change to "1 hours". If an user enables "Whole day" again, it should switch back to "1 days" by default. That's it. No backend changes. It's really just about the UI here when adding new options, not what the backend is doing with these values later (like, treating "0 days" like "1 days" if "Whole day" is enabled - that's a whole different topic, that's why I separated them earlier). So, assuming you indeed change the default in the UI to "1 days" with "Whole day" enabled and an user manually changes that to "0 days", it still is treated the same by the backend.

Just wanted to clarify. If you still don't think that's an improvement: Fair enough, as I said, totally up to you 👍