plone
De/serialize events with start and end timezones
Plone content types already store the start and end timezones. We need to de/serialize these values in Plone REST API. They should be passed through in the following REST API keys in the @content endpoint.
start_timezoneend_timezone
@stevepiercy @thet I had previously reviewed the design document which specified a single timezone field for the Event content type. I see that you updated it today to include both start_timezone and end_timezone.
Having separate timezones for start and end sounds like something that isn't needed 99% of the time, and could lead to a bad UX where users always need to enter the timezone twice. How are we planning to expose this at the UI level (widgets)?
It also makes it more difficult to display the times if we have to consider the possibility that the start and end are not in the same timezone. These days browsers have a nice API for formatting a range of datetimes in multiple locales (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/formatRange) but you can only specify the timezone on the formatter and not separately for the start and end.
So I've been assuming that we want a single timezone field on the event which is decoupled from whatever timezone is actually stored in the tzinfo of the Python datetime objects for start and end.
They should be passed through in the following REST API keys in the @event endpoint.
There is no such thing as an @event endpoint. I guess you mean the event serialization in the normal content endpoint.
Having separate timezones for start and end sounds like something that isn't needed 99% of the time, and could lead to a bad UX where users always need to enter the timezone twice. How are we planning to expose this at the UI level (widgets)?
We could use a similar interface for separate timezones as in Google Calendar 1% of the time.
https://github.com/user-attachments/assets/8dc2739a-43d5-44a4-8627-a20769b13074
Flights, races, and other long-distance journeys are common use cases.
We might not actually implement separate timezones, but I firmly believe having the data available and not using it is better than not having the data and needing it.
There is no such thing as an @event endpoint. I guess you mean the event serialization in the normal content endpoint.
Yes, I had been up for 20 hours. Fixed.
@stevepiercy Thanks, the example from Google Calendar helps me see how we could support that edge case without it being super cumbersome in the UI. As long as we keep that goal in mind, I support the decision to keep start_timezone and end_timezone separate in the API.