Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

De/serialize events with start and end timezones #1878

Open
stevepiercy opened this issue Feb 11, 2025 · 3 comments
Open

De/serialize events with start and end timezones #1878

stevepiercy opened this issue Feb 11, 2025 · 3 comments
Assignees

Comments

@stevepiercy
Copy link
Contributor

stevepiercy commented Feb 11, 2025

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_timezone
  • end_timezone
@davisagli
Copy link
Member

davisagli commented Feb 11, 2025

@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.

@stevepiercy
Copy link
Contributor Author

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.

Screen.Recording.2025-02-11.at.3.37.10.PM.mov

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.

@davisagli
Copy link
Member

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: No status
Status: In progress
Development

No branches or pull requests

3 participants