1letter/fix #178

[1letter]

Fix datetime settings in fc-properties view

• used via ajax call in folder_content view
• use the IPublication Adapter for settings correct datetime
• respect the portal timezone settings
• remove unused imports

[mister-roboto]

@1letter thanks for creating this Pull Request and helping to improve Plone!

TL;DR: Finish pushing changes, pass all other checks, then paste a comment:

@jenkins-plone-org please run jobs

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass, but it takes 30-60 min. Other CI checks are usually much faster and the Plone Jenkins resources are limited, so when done pushing changes and all other checks pass either start all Jenkins PR jobs yourself, or simply add the comment above in this PR to start all the jobs automatically.

Happy hacking!

[jensens]

This mixes the currently stored DateTime with the newly stored datetime. I agree we need to store datetime with timezone everywhere, so for created, modified, effective and expiration. But this gets complex. Just changing it in one place seems dangerous to me. Any opinions?

[erral]

We already discussed many times the issue with datetimes and timezones. I think the last one was in the context of plone.restapi may be @thet and/or @tisto will remember which was the agreement here.

[mauritsvanrees]

As release manager I get nervous when I see such a change during beta...

[jensens]

We already discussed many times the issue with datetimes and timezones.

There is no issue, just store a timezone as pytz (never as offset) with the datetime and all is fine.

[jensens]

during beta.

Changing this is a a PLIP and is complex, so IMO for a 6.1: ok. But not now.

[thet]

As the IPublication schema uses for it's fields zope.schema.Datetime which is based on Python's datetime, this would change the publication dates from DateTime objects to datetime. As others already said, this change would be big win but for Plone 6.1, even if we could consider this a bugfix because the current behavior is inconsistent and broken.

But I do not see how the portal's timezone would be used here. You are stripping the timezone information from the date objects. Out of my head you would need to use something like this:

from plone.app.event.base import default_timezone
from plone.event.utils import pydt
from plone.app.dexterity.behaviors.metadata import IPublication

publication = IPublication(obj, None)
if publication:
    publication.effective = pydt(datetime.strptime(self.effectiveDate, "%Y-%m-%dT%H:%M"), missing_zone=default_timezone(obj, as_tzinfo=True))

Also, we probable need to adapt this in other places too.

But overall, this would be a big win and is actually necessary.

[thet]

@erral the discussion from the 2018 Bonn sprint is here: plone/plone.restapi#493
In short - ISO8601 as a date format for date/times in plone.restapi does not support timezone information - only timezone offsets. For exchanging data it's necessary to convert everything to UTC. But I think this is a different discussion...