IBX-300: Added timezone offset to timestamp

[mateuszdebinski]

Question	Answer
JIRA issue	IBX-300
Type	bug
Target eZ Platform version	v3.2
BC breaks	no
Doc needed	no

Related PR: ezsystems/ezplatform-admin-ui#1752

Checklist:

• Provided PR description.
• Tested the solution manually.
• Provided automated test coverage.
• Checked that target branch is set correctly (master for features, the oldest supported for bugs).
• Ran PHP CS Fixer for new PHP code (use $ composer fix-cs).
• Asked for a review (ping @ezsystems/php-dev-team).

[Steveb-p]

I've noticed that Value::fromTimestamp() method constructs DateTime objects by passing timestamps directly into constructor method. Shouldn't this be changed into:

    public static function fromTimestamp($timestamp)
    {
        try {
-            return new static(new DateTime("@{$timestamp}"));
+            $datetime = new DateTime();
+            $datetime->setTimestamp($timestamp);
+
+            return new static($datetime);
        } catch (Exception $e) {
            throw new InvalidArgumentValue('$timestamp', $timestamp, __CLASS__, $e);
        }
    }

Reason for this is that DateTime objects created using timestamps passed to constructor are actually initialized with offsets +0000, instead of offsets coming from date_default_timezone_get (which in most cases equals server timezone setting). This means that DateTime objects created this way will have potentially different offsets, therefore generating different values for, for example, DateTime::format method.

This might be the reason why those datetimes differ in the first place. Adding default offset would cause that an actually invalid timestamp would be stored (!).

See: https://www.php.net/manual/en/datetime.construct.php#refsect1-datetime.construct-parameters

Note:

The $timezone parameter and the current timezone are ignored when the $datetime parameter either is a UNIX timestamp (e.g. @946684800) or specifies a timezone (e.g. 2010-01-28T15:00:00+02:00).

EDIT: I'm rather sure that this is the root of the issue you're fixing. As I said, you're storing offset info into timestamp (timestamps should not change depending on timezone). When creating DateTime from timestamp we should set the default timezone instead (which happens when calling DateTime's constructor without argument).

[Steveb-p]

Please address the issue raised in the comment.

[mateuszdebinski]

Please address the issue raised in the comment.

The proposed change actually works as you describe, but then there is a problem on the front side, so I need to verify the JS files that are responsible for it

[alongosz]

Looks like we're missing test coverage

[Steveb-p]

LGTM. @alongosz do you think we need some more tests for this?

[Steveb-p]

One thing to note: do we need to migrate anyone? Can any customer have timestamps stored with an offset?

[mateuszdebinski]

One thing to note: do we need to migrate anyone? Can any customer have timestamps stored with an offset?

I think no, there shouldn't be any incorrect data saved anywhere, because when creating this item we changed the timestamp (add offset timezone) via JS now we do it in PHP

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[Steveb-p]

Similar issues exist in eZ\Publish\Core\FieldType\DateAndTime\Value::fromTimestamp and eZ\Publish\Core\FieldType\Time\Value::fromTimestamp.

[mateuszdebinski]

merge up - done