Allow ignoring timezone for date only polls

[Zocker1999NET]

Describe the goal you'd like to achieve

As a poll participant I want to be able to view date only polls as such even if my timezone differs from the timezone of the creator, because it makes reading and filling out such a poll more easy. This is a poll where such feature could be useful:

Describe possible solutions

Add a setting, which will allow ignoring the timezone of a poll if such poll only consists of full days. If such setting is enabled, the example poll from above should look like this (ignoring the change of language):

Another solution could be that the poll app allows configuring the timezone I want to use, which then will further ignore the timezone of the browser.

Additional context

My browser sends the timezone UTC to all websites for privacy reasons, including Nextcloud. This is most of the time usable as good websites will list the timezone they are using to display the time so I know that. In the Nextcloud calendar, I configured my correct timezone so that the calendar will use my home timezone. However the creator of the poll has this setting not enabled and lives currently in a UTC+2 zone. If he/she/it creates the poll without inserting any times. I see the poll converted to my timezone which makes it really hard to read, because then a poll answer which reflects "Tuesday" will be displayed as a "Monday to Tuesday" answer, which I often interpret as "Monday".

[dartcafe]

The use case, where I currently reside in another time zone, but am planning in my home time zone is new and a valid one.

Have to check some implementation variants. But this will last a little bit, so please be patient. ;-)

[dartcafe]

Notes for myself while thinking about it:

• Add owner's timezone to poll informations
• Check timezone of participant against owner's timezone
  • Allow participant to chose the presentation between owner's and own timezone
  • Possible bonus: chose free timezone for presentation
• check timezone change with moment and respect summer time

[PhrozenByte]

Isn't it rather a bug if a date-only poll suddenly shows a time? IMO a date-only poll should never show a time, no matter the time zone. By setting 2022-04-12 without a time, I don't mean 00:00 o'clock, I either mean the whole day, or some not yet decided time, thus the timezone doesn't matter (yet).

IMO the issue is with how polls currently stores date options: Any time is converted to a ISO 8601 string in UTC. Options without a time are stored as time period covering the whole day. I'm in CEST/UTC+2, thus creating a date-only option for 2022-04-12 is stored as 2022-04-11T22:00:00+00:00 - 2022-04-12T22:00:00+00:00. This naturally causes issues...

Instead of adding a field with the owner's timezone, I rather recommend dropping the UTC conversion. So, if I choose 2022-04-12 12:00, polls should store this option as 2022-04-12T12:00:00+02:00. Since both JavaScript (resp. Moment.js) and PHP are timezone-aware, this date will be shown as 2022-04-12 11:00 to someone in UTC+1. By comparing the participant's timezone with the stored timezone you could still show a small notice with an option to switch timezones (moment() will convert the date string to the user's timezone by default; to get a Date object with the original timezone, use moment.fromZone() instead).

Considering date-only polls, there are two possible solutions (I assume that the first is easier to implement):

1. By dropping the UTC conversion it's easier to handle the situation properly: If I now choose 2022-04-12, it will be stored as 2022-04-12T00:00:00+02:00 - 2022-04-13T00:00:00+02:00. By using moment.fromZone() you get a Date object using the original time zone, thus .format('HH:mm:ss') still yields "00:00:00" for both times, allowing you to assume that it is a date-only option.

2. Since 2022-04-12 (i.e. without any time information) is still a valid ISO 8601 date string, you could store a date-only poll option without any time information. Moment.js will then assume 00:00 o'clock in the user's timezone. It's easy to check whether the original date string contains time information and if not, you can safely show it as date-only option.

[dartcafe]

We have different options to define a date option but all options are stored as a timestamp with a duration:

• date only (which covers a whole day without defining a special time of the day, persisted with a 24h duration)
• date with time (which represents a moment, persisted with duration 0)
• date with a duration (which covers a time span with start and end, persisted with duration end minus start)

The fact, that a timestamp is used includes always a time information. So a date only option is defined as a date option with a start at local time 00:00 at the given day with a 24 hour duration.

With a timezone shift, this information is altered in the presentation layer depending on the user's timezone. This by intention because if someone in TZ UTC adds a date only event he understands it as just a date specification and not more, but a viewer in the same TZ without further information may understand this option as sometimes during the day. So far the interpretaition is rather congruent, if both users reside within the same timezone. But a participant now in TZ UTC+/-12 can't be sure, which day and when is addressed.

For sure, we can optimize the presentation and interpretation. But what gives a good UX in the end? I guess dealing with timezones is not common for most people.

So it's not a bug, it's a feature. 😄

A change in the logic should be a well thought change, because I bet we can adjust the time after the next issue, which addresses the change whith the opposite arguments. 🎉

Because of this I think it is a compromise to let the viewer decide, which timezone setting he wants to apply (his, the owner's or a free defined). but I am open for every proposal, mostly preferred as a mockup, so endusers can have a glue, what is meant. The rest is just if ... then ... else and time conversation.

Moment is a good swiss army knife for this, but we also have to deal with the backend's logic.

Edit: And thanks for yout thoughts. 👍

[PhrozenByte]

Sorry for the late response. I'm not sure whether we're talking about the same things here 🙈 Let's revamp to make it a bit more clear:

There's a technical and a UX perspective on this.

Let's talk about the UX perspective first:

No matter the implementation details, interpreting a date-only poll option as covering the whole day isn't quite right from a UX perspective (from a technical perspective it might still make sense to do so nevertheless, but that's another topic). If a user chooses to create a date-only poll option, the user specifically decides that time does not matter. Even on a best effort basis you can't reasonably assume that the user meant 00:00 to 24:00, as this is a highly unlikely time period for human beings. Depending on the context it might rather mean business hours, or after work hours, or any other, possibly not even yet decided time, or time period. We simply can't know. Context matters.

Thus I believe that bringing a user's timezone into play is just wrong for date-only polls, as you can't possibly know whether a difference of 1 hour is a problem, or of 12 hours - and where to draw the line. You really shouldn't - likely wrongfully - assume that the poll owner actually meant 00:00 to 24:00 and therefore show different times for users in different timezones, as this is most likely wrong and causes confusion for sure (see OP).

A date-only poll option should be shown as date-only poll option, no matter the timezone. If the timezone differs, a warning should be shown, informing the user about the matter, so that the user can decide accordingly depending on the context of this particular poll.

Just to be clear: We're on the same page that it should be possible for participants to view times not just from their own timezone, but also the owner's timezone. From the UX perspective I'm solely talking about date-only poll options, i.e. those without a time. This is different for the technical perspective, as doing this right solves the issue for both date-only and date-time poll options, and makes implementing this timezone switch way easier and less error-prone.

Speaking about the technical perspective:

I can't really comprehend why you said that poll options are stored as timestamps, because this is simply not true when looking at the database. Poll options are stored as ISO 8601 datetime strings. Surely, in the course of processing the values you convert these datetime strings to timestamps back and forth, but they are nevertheless stored as ISO 8601 datetime strings. We can use that.

Converting these datetime strings to timestamps is the reason why we loose the info about the original timezone - and it's also the reason why date-only poll options are shown with unexpected time designations in different timezones. By dropping the timestamp resp. UTC conversion you can "kill multiple birds with one stone": First, you can still store date-only poll options as time span from 00:00 to 24:00, but can now easily identify such options from any other timezone using moment.fromZone(). Second, you can now compare the original timezone (the owner's timezone) with the participant's timezone and show the warning and option to switch timezones for display. Third, daylight saving time won't be an issue anymore.

[dartcafe]

UX

Don't get me wrong. I highly appreciate the time and effort you invest for this really good explantion. I like that! I am pretty sure, that I totally understand the issue. But the implementation is now as it is and took a lot of time. Realy a lot.

I can't really comprehend why you said that poll options are stored as timestamps, because this is simply not true when looking at the database

Yes, it is stored (additionally), but it is simply not used. The only relevant information is the timestamp. And the timestring is 100% equivalent with the timestamp (plus duration) as it is stored in UTC. So there is no information loss.

Moment btw. is no satisfying solution, because most of the logic is handled in the backend. Besides the fact that is should be replaced.

Context matters.

Absolutely. But I can only guess what the context is, because it is only present at run time, on the user's computer, at the time the user works with polls. Not while developing.

Trust me: I will find a solution. But not yet. I need time for that.

[ultr41337h4xor]

Adding my voice to this - we just had a problem, almost identical to that of the original poster @Zocker1999NET here. Friend has a browser that sends UTC as the timezone for privacy reasons, making all dates (for example 17th of August) appear as date ranges (because options in the poll set as entire days (I assume) have a time of 00:00, the date range shown is 16th of August 22:00 - 17th of August 22:00). This was very confusing for us and put a wrench in our planning as we were trying to figure out what happened and what the friend wanted to actually vote for (as he didn't realize at first that his display of the dates differed from the intended one).

@PhrozenByte's suggestion sounds like the ideal solution for covering the above use case. Having a warning pop up, informing the voter that his timezone differs from that of the poll creator's and offering him a choice to view the poll as it appears in the poll creator's timezone or his own timezone (in case it actually matters for the user) seems to cover all use cases.

#2851 sounds related to this issue

[hansdez]

My friend was utterly confused when they saw the below when on holiday in a timezone where it is one hour earlier then where we live:

I was too, as I had specifically made a date-poll without any times. It took us a while to understand it was caused by the timezone.

I was about to file a bug report, but then realized it might actually be a feature. Now I've found this issue. Am now rooting for a solution…

[andreas-1107]

I just commented on the other issue: #3699

Perhaps the two issues could be merged? It seems to me they are aiming to solve the same problem.

Thanks for the good work on the polls app, I use it all the time 👍👍