Store UTC datetimes

[thet]

At the Bonn sprint we discussed options on fixing issues with plone.restapi and plone.app.event regarding timezone handling and storing date/time values converted to UTC in general.

Refer to this discussTion: plone/plone.restapi#493

Note:

• In plone.app.event 1.x we stored timezone-aware Python datetime converted to UTC.

• We had a separate timezone field.

• A data_postprocessing event handler converted from local- and timezone-naive datetime values to UTC datetime values using the timezone field after saving. This worked only through the web - programmatically it had to be done manually.

We changed that due to bad developer experience caused by the data_postprocessing step.

Currently we store timezone-aware Python datetimes with the portal's default timezone.

Also note that correct timezone information is only needed for recurring events. For recurring events it’s mostly necessary to repeat on the same time of the day, even after DST (Daylight Saving Time) changes. For correct calculations the timezone information is necessary. For other use cases it’s normally enought to display the date/time in the users timezone (can be retrieved via browser request headers).

We want to get back to UTC converted values because:

• Timezone aware Python datetimes in a local timezone are ambiguous:
  (e.g. 2017-10-29 02:30 in TZ Europe/Zurich is ambiguous, could be 2017-10-29 01:30 or 2017-10-29 00:30 in UTC)

• Most libraries expect UTC values and recommend to datetimes in UTC.

• JavaScript’s date/time serialization uses the ISO8601 format ( https://en.wikipedia.org/wiki/ISO_8601 ) which does not have a concept of timezones but only UTC offsets. When exchanging information with such systems it is advantageous to use UTC.

We propose these changes in plone.app.event:

• We store timezone-aware Python datetime values converted to UTC.

• We store the timezone information as a string in a separate field (e.g. "Europe/Vienna". This is only needed for recurring dates where it is important to keep the same time in the local timezone over DST changes).

• The date/time input widget's timezone should automatically be selected (via Browser's request header information) and exposed. Users should be able to change them in the UI (compare Google Calendar).

• Input fields need to expose their timezone to which they are set to.

• The user's timezone selection could be stored in local storage - maybe the portal's and user's timezone settings in plone.registry are not needed anymore.

• Values are displayed in the users timezone, converted by a frontend JavaScript library like moment.js.

• Developers are encouraged to convert their datetimes to UTC. Helper methods for converting Python datetime or Zope DateTime values from the users timezone to UTC are already available in plone.app.event.base and plone.event.utils.

Additionally we need to fix effective and expiration dates to be also stored in UTC and converted from the user's timezone. This is not done yet - they are stored in UTC only and do not respect the portal's timezone setting. They take the user's input as if it were set in UTC.

This would be a major change for plone.app.event 4.0.

/cc @tisto @buchi @csenger @sneridagh @erral

[tisto]

@thet is that something that we should consider to implement in Plone 6?

[tkimnguyen]

We have a client who is running into events not being displayed with the correct times (or dates) because of time zone issues, so I'd rather something changed before Plone 6...