Cannot set events with a user preferred time zone

[stevepiercy]

Cross-posting from https://github.com/plone/plone.org/issues/141

It is not possible to create local events with a local time zone in plone.org or in the Volto demo, but I can in the Classic UI demo.

Classic UI Demo behavior

• Login to https://classic.demo.plone.org/en as admin/admin.
• Go to Date and Time control panel.
• Observe the only available time zone is Europe/Berlin by default.
• Add any time zone, such as America/Los_Angeles, and click Save.
• Click Home to return home.
• Create a new event. The event inherits the site's default time zone.
• Go to User Preferences, select the available time zone, America/Los_Angeles, and click Save.

Plone.org and Volto Demo behavior

• Repeat all the steps above. Observe that the User cannot set their preferences for a time zone, and must therefore rely upon the site preference for a time zone when creating events.

I don't know whether this is a bug in Volto or some other dependency.

[tiberiuichim]

@stevepiercy AFAIK, in Volto the datetime is TZ-aware, and it's extracted from the user's browser.

[stevepiercy]

We want to be able to schedule an event in a different time zone than the user's browser, allowing the user to set a preferred time zone. The use cases include traveling outside one's local time zone or scheduling an event that takes place outside one's local time zone. The Volto implementation does not allow either use case, whereas Classic UI allows both. In America this is a serious problem, for example, where an organization is headquartered in the Eastern time zone but wants to schedule an event in the Pacific time zone.

[IshaanDasgupta]

@stevepiercy is adding a timezone options in the user preferences okay ?

[stevepiercy]

@IshaanDasgupta Volto should have feature parity with Classic UI.

[IshaanDasgupta]

@stevepiercy sorry but if I am understanding the problem wrong let me know.

what I understand is that in volto we can add more timezones but we can't set a preferred timezone so adding an option to select the timezone in preferences will solve the issue right ?

[stevepiercy]

That is half the problem. Once the user sets a preferred timezone, we need to ensure that events that the user creates are in that same preferred time zone.

One more thing that was pointed out to me by @ericof is that Volto does not provide an .ical link for events. That should also be included. But maybe that should be a separate issue? We definitely need that in Volto, especially for PloneConf and sprints.

[IshaanDasgupta]

Yes, I am planning to overwrite the timezone(by getting it from the redux store) whenever the user selects a time also I am planning to add a text below the date-time picker that the time is being selected in the respective timezone. If no preference is selected then that text will not be displayed and the default timezone will be used. Also, I am not familiar with .ical links so, could you create a new issue for that and after implementing this, I'll look into that if no one has until then.

Is that alright ?

[stevepiercy]

I don't know whether getting event information from the redux store is the best way to get something that is stored in the backend. Although as @tiberiuichim points out about Volto extracting the timezone from the user's current location, I think that method prevents an editor from creating events in other time zones. I would think the best way would be to use the Plone REST API event endpoint. It would be worth identifying how Classic UI handles events as well.

[ericof]

That is half the problem. Once the user sets a preferred timezone, we need to ensure that events that the user creates are in that same preferred time zone.

One more thing that was pointed out to me by @ericof is that Volto does not provide an .ical link for events. That should also be included. But maybe that should be a separate issue? We definitely need that in Volto, especially for PloneConf and sprints.

I corrected myself, Volto does provide the .ics download link (as can be seen in this image "Baixar evento" )

[IshaanDasgupta]

@stevepiercy as you mentioned, I went through the classic UI once again. In the classic UI the event date-time is always displayed in the timezone in which it was created (so if my preference is Europe/Berlin and the event was created in America/Los_Angeles the date-time in the event would be displayed in the America/Los_Angeles and not be converted to my preferred timezone). Do we want the same in volto ? Or we could keep all date-times in UTC and when rendering we could convert them to the default/preferred timezone (personally this makes more sense but then it would not be similar to the classic UI).

Also I was referring to getting the preferred timezone from the redux store not any event information.

[stevepiercy]

if my preference is Europe/Berlin and the event was created in America/Los_Angeles the date-time in the event would be displayed in the America/Los_Angeles and not be converted to my preferred timezone

This is exactly what we want. In most use cases, the event's time zone will be that of its location. One exception is where there is no physical location, such as online only events such as Plone Tune Ups. In that use case, it would probably be best for the admin to enable UTC and editors set the event start and end dates and times in UTC.

As an aside, did I just discover something that has been missing in Plone for all time? I think that relying on the user's preferred or site's default time zone setting is wrong, but this issue will work with what exists now in Plone. IMO both Classic UI and Volto should allow an editor to set the event's time zone and location, regardless of their preferred time zone setting, instead of inheriting it from the user's or site's time zone setting. Thus I could create an event in the Eastern US time zone while residing in Pacific US time zone. The event would be displayed in its time zone, not the user's or site's.

[IshaanDasgupta]

@stevepiercy sorry for the late reply, I was a bit caught up. Yes, I totally agree that an editor should be able to create events in timezone regardless of his preference. So, to implement that, I could add a timezone drop down when creating the event so the editor is able to select any timezone for that event but, then what would be the meaning of having preference ? We could make the preference the default timezone for the user for example I am in India but if I were to chose a US timezone, all things will be converted to the US time (except for the date-time which have a specific timezone associated with them) or we could skip implementing the user preference timezone for now.

Is the drop-down idea okay or you have any other ideas for the implementation or would you recommend to implement it in a similar way to Classic UI ?

[stevepiercy]

what would be the meaning of having preference ?

The user and site preferences would be fallbacks, when no time zone is selected when creating an event. In other words, timezones order of preference would be: Event > User > Site.

In Classic UI, I think only user and site time zones can be set, and that events are created according to the user's preference first, then the site if no user preference is set. This needs to be verified. I posted to the Community Forum to get more feedback: https://community.plone.org/t/time-zone-for-an-event-content-type-cannot-be-arbitrarily-set/18249

The select menu option is OK.

However, we need to determine how to implement it in the backend in Plone. As far as I can tell in Plone REST API, the event endpoint does not have a timezone attribute. This could also mean that there is no timezone attribute for the event content type in Plone itself. That needs to be researched.

[IshaanDasgupta]

The user and site preferences would be fallbacks, when no time zone is selected when creating an event. In other words, timezones order of preference would be: Event > User > Site.

The select menu option is OK.

However, we need to determine how to implement it in the backend in Plone. As far as I can tell in Plone REST API, the event endpoint does not have a timezone attribute. This could also mean that there is no timezone attribute for the event content type in Plone itself. That needs to be researched.

Ok got it. I have not looked into Plone REST APIs but I'll take a look as to how events are stored and handled there.

[thet]

@stevepiercy when plone.app.event was created, the plan was to support event-related timezones. There would even the possibility to support different time zones for the start and end date.

It wasn't implemented because lack of a design proposal and lack of time.

[stevepiercy]

@thet thanks for the package history. That helps. For convenience:

• plone.app.event documentation
• plone.app.event repository

While digging, I also found this in pytz's readme:

Projects using Python 3.9 or later should be using the support now included as part of the standard library, and third party packages work with it such as tzdata. pytz offers no advantages beyond backwards compatibility with code written for earlier versions of Python.

Plone 6.0 supports Python 3.8-3.11, so we can't use only the Python standard library and drop pytz. Maybe in 6.1 we could do that. pytz currently supports up to Python 3.12.

I'd like to work on this, at least creating a design proposal or PLIP and being its champion, if not working the code.

Is it correct that until this feature is implemented in plone.app.event, it cannot be implemented in Volto?

[davisagli]

@stevepiercy https://www.youtube.com/watch?v=XZlPXLsSU2U is a good fairly recent talk on handling timezones in Python, including the new zoneinfo module

[thet]

@stevepiercy that's not bad news that pytz is obsolete. It's a good library but also importing and loading it took several seconds as the database behind pytz is huge. OK, maybe importing tzdata in core Python is still slow, I‌ don't know. However, having fewer dependencies is always good.

@stevepiercy and having you as a champion on implementing event-related timezone support is definitely good news. I‌ can probably assist if there are any questions. I was back then the main contributor on plone.app.event.

Regarding Volto: I don't think they need this feature implemented in ClassicUI before they can implement it. The foundations are already here. The start and end dates are stored with timezone information (thus, they could also be different). For the catalog everything is translated to UTC. It's mainly an UI issue.

IIRC there is a problem with JavaScript and timezones in general, that core JavaScript has poor timezone support. Date/time only know UTC offsets. But that is not enough to calculate daylight saving time changes, for example, which is regulated by country laws. Volto therefore needs to separately serialize the timezone information for the REST API endpoints dealing with datetimes. We discussed this issue 5 years ago in Bonn. Something was done, also by myself (cant remember what OTTOMH) but apparently there is still not timezone information in the event's REST API endpoint, looking at the resonse on https://demo.plone.org/test-event

[IshaanDasgupta]

@stevepiercy if its okay, I would like to work on the implementation part in volto.

[rnunez80]

The issue with the time in volto is more than just the events and recurrences, it also affects effective and expiration, and also volto-form-block

[stevepiercy]

@IshaanDasgupta thank you for stepping up. As @thet and I both mentioned, you will need to enhance the event REST API endpoint, as well as work on the Volto frontend part. Please let me know if you need any direction for how to proceed.

@rnunez80 can you elaborate what you mean? I think you mean the publishing datetimes for "effective" and "expiration" for all content types, but I am not sure. I also don't know what is volto-form-block.

[thet]

That's right @rnunez80 and @IshaanDasgupta very nice if you want to step up for this, but since this is not a simple bugfix but needs some planning and specification you need to coordinate with the other Volto people.

[IshaanDasgupta]

@stevepiercy and @thet thanks a lot, right now I am looking into the rest APIs as I not familiar with them

I'd like to work on this, at least creating a design proposal or PLIP and being its champion, if not working the code.

The PLIP would help a lot, I know it's quite a large issue and I am totally fine working alongside someone but the issue looks very interesting and I would love to contribute.

[rnunez80]

@rnunez80 can you elaborate what you mean? I think you mean the publishing datetimes for "effective" and "expiration" for all content types, but I am not sure. I also don't know what is volto-form-block.

Here is a video of the effective date issue in this video I set the effective date about 27 min before the current time but it shows as effective and will not show on the site for the next ~4 hours due to time zone (utc -4)

Date widget Issue in volto-form-block date selected 2023-12-04, date on email 2023-12-03 (I believe is because the date selected would be 2023-12-04 12am but due to time zone -4 it is changed to 2023-12-03 8pm)

[davisagli]

@rnunez80 The time zone issue with effective and expiration date is a separate issue, not related to this one which is about storing a time zone as part of the Event content type. There is a PR in progress to fix it: https://github.com/plone/plone.restapi/pull/1192

The issue with volto-form-block should be submitted in that repository.

[IshaanDasgupta]

was looking into the code of plone.restapi and finally found the problem, due to the conversion of date to ISO format date, the tz info was lost. @thet found this commit by you, the problem is in the 'datetimelike_to_iso' function, there is also a comment by @gotcha as to why did you keep the tz code commented out, could you let me know the reason for that. Like will there be any issues if we were to include the tz info which you noticed at the time ?

Apart from this, I wanted to ask a few things :

• There are 2 things which we can do to solve this, first is to just make the rest endpoint return dates with tz info but if we were to do that, we would not be able to create event dates which don't need a timezone like online events as @stevepiercy mentioned earlier. If we want that to be possible, is there any other solution apart from adding a separate timezone attribute to the event content type ?
• If we were to change the plone.restapi to return datetime with tz info would that cause problems to existing volto or any custom frontends which use plone.restapi ? (I tried to look into this and did not find any problems as the datetime always had the tzinfo internally it was just not returned in the response)

[stevepiercy]

• we would not be able to create event dates which don't need a timezone like online events as @stevepiercy mentioned earlier.

That is not correct. All event content types should have timezones, using the fallback scheme, as I mentioned in my earlier comment.

If we were to change the plone.restapi to return datetime with tz info would that cause problems to existing volto or any custom frontends which use plone.restapi ?

Good question. I assume it would be tested in Volto, plone.restapi, and plone.app.event. I'll include that in the PLIP I am drafting as a potential risk.

[thet]

@stevepiercy

I just got reminded that we already had support per-field timezones in Plone 5. It's done like that:

from plone.app.event.base import default_timezone
from plone.app.z3cform.widget import DatetimeFieldWidget
from plone.autoform import directives
from zope import schema
from plone.supermodel import model

class IExampleDate(model.Schema):
    directives.widget(
        "example_date",
        DatetimeFieldWidget,
        default_timezone=default_timezone
    )
    example_date = schema.Datetime(
        title="Example date",
        required=False,
    )

This renders something like:

Only, it seems like full of bugs. I'm currently evaluating (but not yet fixing) the situation.

Note: This is for Plone 5, and not yet available in Plone 6 ClassicUI. But we have a design concept at least - which of course can be improved.