Handle timezone in publication fields (effective and expires)

[cekk]

This could fix plone/volto#2597

The failing test is because also if i customize env var, i can't save a DateTime value in that field with the wanted timezone.

Anyone have an idea on how to fix it? @buchi ?

[mister-roboto]

@cekk thanks for creating this Pull Request and help improve Plone!

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass.

Whenever you feel that the pull request is ready to be tested, either start all jenkins jobs pull requests by yourself, or simply add a comment in this pull request stating:

@jenkins-plone-org please run jobs

With this simple comment all the jobs will be started automatically.

Happy hacking!

[tisto]

@jenkins-plone-org please run jobs

[tisto]

@jenkins-plone-org please run jobs

[cekk]

@jenkins-plone-org please run jobs

[netlify[bot]]

✅ Deploy Preview for plone-restapi canceled.

Name	Link
🔨 Latest commit	7c89fb677c0baabb3ca3b7660a980aea704aadeb
🔍 Latest deploy log	https://app.netlify.com/sites/plone-restapi/deploys/6682ae32afa2140007f988a8

[avoinea]

Holy mother of... this is here for 2 years and nobody took care of it? :smile:

I can confirm @cekk 's conclusions from here https://github.com/plone/volto/issues/2597#issuecomment-895114458

How to test and reproduce:

1. Start plone backend with TZ env

docker run -it --rm -p 8080:8080 -e TZ="Europe/Berlin" plone/plone-backend

2. In Volto publish a News items with publishing date and time after a half an hour
3. In Volto add a listing block showing all news before today
4. The News should not be listed yet, but it is.
5. Play with the Publishing Date until the News item disappear from the listing block
6. Check the portal_catalog entry and you'll notice the EffectiveDate is actually UTC - 2 :scream:

[erral]

We have been hit by this too, and I can confirm that with this changes the original datetime as entered in Volto interface is correctly saved in Plone.

We configure our Zope instance passing the TZ = Europe/Madrid environment variable.

In all cases here, I have Europe/Madrid configured as a default timezone in Plone.

Item saved with the following datetime through Volto: 2023-08-28 10:00:00

Previous scenario (without this branch):

>>> news = app.Plone.komunikazioa.albisteak['albistea-2023-08-28-10-00-00']
>>> news
<FolderishNewsItem at /Plone/komunikazioa/albisteak/albistea-2023-08-28-10-00-00>
>>> value = news.effective()
>>> value
DateTime('2023/08/28 08:00:00 GMT+2')
>>> value = value.asdatetime()
>>> value
datetime.datetime(2023, 8, 28, 8, 0, tzinfo=<StaticTzInfo 'GMT+2'>)

Current scenario (with this branch)

>>> news = app.Plone.komunikazioa.albisteak['albistea-2023-08-28-11-00']
>>> news
<FolderishNewsItem at /Plone/komunikazioa/albisteak/albistea-2023-08-28-11-00>
>>> news.effective()
DateTime('2023/08/28 10:00:00 GMT+2')
>>> news.effective().asdatetime()
datetime.datetime(2023, 8, 28, 10, 0, tzinfo=<StaticTzInfo 'GMT+2'>)

I have made a test without adding the TZ environment variable in the instance configuration and the behavior is the following:

Previous scenario (without this branch)

>>> news = app.Plone.komunikazioa.albisteak['albistea-2023-08-28-12-00']
>>> news
<FolderishNewsItem at /Plone/komunikazioa/albisteak/albistea-2023-08-28-12-00>
>>> value = news.effective()
>>> value
DateTime('2023/08/28 08:00:00 GMT+2')
>>> value.asdatetime()
datetime.datetime(2023, 8, 28, 8, 0, tzinfo=<StaticTzInfo 'GMT+2'>)

Current scenario (with this branch):

>>> news = app.Plone.komunikazioa.albisteak['albistea-2023-08-28-12-00']
>>> newd
<FolderishNewsItem at /Plone/komunikazioa/albisteak/albistea-2023-08-28-12-00>
>>> value = news.effective()
>>> value
DateTime('2023/08/28 10:00:00 GMT+2')
>>> value = value.asdatetime()
>>> value
datetime.datetime(2023, 8, 28, 10, 0, tzinfo=<StaticTzInfo 'GMT+2'>)

[stevepiercy]

@tisto @cekk @erral @avoinea @sneridagh can we add this to the Volto Team meeting agenda? This bug has been hanging around for almost 3 years now without resolution. The tests are broken, too.

[sneridagh]

@davisagli @jensens @thet related with current dates handling. Aside from the new fixes that we are working on already, we probably will need this patch for now. Are you able to take a look?