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

[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!!!