@nzambello could you have a look here please? It seems this might have something to do with your code from: https://github.com/plone/volto/blob/master/src/helpers/Utils/Utils.js#L155

I did some further research and it might actually be a problem with Plone REST API. checking the returned value for "effective" on an item published at 2021-08-02T12:47:15 GMT+2 (German local time) returns an effective date of "2021-08-02T12:47:15" without any Timezone reference.
While the created field has "2021-08-02T10:47:09+00:00". So that field seems to get normalized to GMT while the "effective field does not.
So @nzambello probably nothing wrong with your parseDateTime function, but a problem in p.restapi

@buchi I saw you implemented some stuff regarding DateTime in p.restapi. This comment seems to sum up the issue we are having: https://github.com/plone/plone.restapi/blob/02421afe76b53414ee569bb42077248b45d6e8e8/src/plone/restapi/deserializer/dxfields.py#L96

Can you maybe explain why this is? Looking at the portal_catalog the time zone information we need is stored in the object:

As metioned by @nzambello i could have found a possible solution.

The problem is that for effective and expires there are custom field setter and getter that strips timezone infos for some reasons related to z3cform widgets i think.

The problem is that when Volto post that date, it is a UTC string.
Then restapi deserializer takes it and convert it to a datetime object with right timezone but not "localized" (so the hour is still the UTC one).
After that, the date is passed to field's setter, that takes the date items (day, month, year, hour, minutes) and ignore the timezone info, so the date will be saved with a wrong hour.

With my patch i simply "localize" the date in deserializer to be able to pass the correct hour to the setter.

I don't know if this could be a good solution to be moved into plone.restapi (i made these changes only for these two fields).