You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
DateTime modify with unixtimestamp (@) must work like setTimestamp #9891
changed the title [-]DateTime modify with unixtimestamp (@) must works like setTimestamp[/-][+]DateTime modify with unixtimestamp (@) must work like setTimestamp[/+]on Nov 4, 2022
Hi welcome @goncons when you use @ format you are using a UTC time zone, currently modify does not change the time zone. If timezone origin it's America/Lima modify add "Unix Timestamp" with @ format.
timestamp
Unix timestamp representing the date. Setting timestamps outside the range of int is possible by using [DateTimeImmutable::modify()](https://www.php.net/manual/en/datetimeimmutable.modify.php) with the @ format.
substantially DateTime::__ construct, DateTime::modify and strtotime parse a date or a format, the construct if it is already present Unix Timestamp the second argument timezone not accepted.
<?php$date = newDateTime('2022-01-01', newDateTimeZone('America/Lima'));
$date = newDateTime('@' . $date->format('U'));
echo$date->format('Y-m-d H:i:s e');
echo"\r\n";
$date->modify('2021-01-01 00:00:00 America/Lima');
echo$date->format('Y-m-d H:i:s e'); // DateTime::modify Alters the timestamp, don't change timezone from UTC to America/Lima?>
Hi @hormus my point is that the Unix Timestamp it is always in UTC, but looks like the @ format is treating the timestamp as "local" Unix timestamp, see this example:
Why the @ format is changing the values of the timestamp ?. @cmb69 that comment in the documentation sounds weird, to me it sounds like the @ format changes the timezone of the instance of the DateTime class, that is not the case.
it is not a bug modify does not change timezone, the value is UTC obviously +5 hours in object created America/Lima -05:00
i updated my previous comment inserted the explicit timezone in modify
For me This documentation issue
modify don't change timezone
<?php$timestamp = 1667595977;
//America/Lima -05:00 convert for Unix timestamp +05:00$date = newDateTime('now', newDateTimeZone('America/Lima'));
$date->setTimestamp($timestamp); // $timestamp (UTC) automacamally convert for timezone America/Lima ex. $timestamp - (18000)echo$date->format('U');
$date->modify('@' . $timestamp); // Set Unix timestamp $timestamp + timezone (18000)echo"\r\n";
echo18000 + ($timestamp) . ' = ' . $date->format('U');
$date->modify('@' . 0); // Set Unix timestamp to 0 and timezone America/Lima -05:00echo"\r\n";
$date->modify('+' . $timestamp . ' sec'); //Add seconds to America/Limaecho$date->format('U');
?>
Expected result:
1667595977
1667613977 = 1667613977
1667613977
php 5.3.6 Absolute date/time statements now take effect. Previously, only relative parts were used.
@hormus If that is the intended behaviour then there is a "bug" in the documentation or the PHP/DateTime definition of Unix Timestamp for the @ format, bacause the Unix Timestamp is Always in UTC and the @ format is treating it like is a "local" timestamp (if you have to add or subtract the timezone offset).
Hi @goncons can you do an example of DateTime::modify which changes the timezone of how it was created?
The Unix timestamp or @ format is the UTC time measurement, if the object uses an immutable timezone (for DateTime::modify) it makes sense to set Unix timestamp without calculating the timezone.
Since exists DateTime::__construct or (DateTime::setTimestamp int) the current use of @ format inside the DateTime::modify function is not to be modified for two reasons 1) to avoid a useless check and 2) It exists since php 5.3.6 the change causes a break
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).
<?phpdate_default_timezone_set('UTC');
$date1 = newDateTime('@0'); // UTC$date2 = newDateTime('now', newDateTimeZone('America/Lima'));
$date2->modify('@0'); // php >= 5.3.6 Set Unix timestamp to 0var_dump($date1->format('Y-m-d\\TH:i:s\\Z'), $date2->format('Y-m-d\\TH:i:s\\Z')); // Output display UTC, Attention the forced output in UTC can differ from the input, if DST or if different from civil date?>
Epoch time (also known as the Unix time) 1970-01-01 00:00:00
$date1 have UTC timezone and $date2 have America/Lima with same output display and different timezone offset (UTC +00:00 America/Lima -05:00 or -04:00 with DST active)
the maintainer of the date @derickr will decide the desired behavior. I ask for a note for good code practice it is not recommended to enter the timezone as it is ignored by DateTime::modify if you want to change the timezone use DateTime::setTimeZone or if you use @ format use DateTime::__construct
Indeed the way the docs are structured, the formats are documented independently of the methods using them, and the relevant page states The "Unix Timestamp" format sets the timezone to UTC. without anything like not for modify
To me this is clearly just a bug and the fix is obvious...
Activity
[-]DateTime modify with unixtimestamp (@) must works like setTimestamp[/-][+]DateTime modify with unixtimestamp (@) must work like setTimestamp[/+]cmb69 commentedon Nov 4, 2022
Hmm, the documentation says:
This seems to be a temporary measure only: https://3v4l.org/GR7Tc
@derickr, can you please clarify?
hormus commentedon Nov 4, 2022
Hi welcome @goncons when you use @ format you are using a UTC time zone, currently modify does not change the time zone. If timezone origin it's America/Lima modify add "Unix Timestamp" with @ format.
DateTime::modify — Alters the timestamp
The "Unix Timestamp" format sets the to UTC.
https://www.php.net/manual/en/datetime.settimestamp.php
substantially DateTime::__ construct, DateTime::modify and strtotime parse a date or a format, the construct if it is already present Unix Timestamp the second argument timezone not accepted.
Expected result:
goncons commentedon Nov 4, 2022
Hi @hormus my point is that the Unix Timestamp it is always in UTC, but looks like the @ format is treating the timestamp as "local" Unix timestamp, see this example:
The expected result from my point of view must be:
but the obtained result is:
Why the @ format is changing the values of the timestamp ?.
@cmb69 that comment in the documentation sounds weird, to me it sounds like the @ format changes the timezone of the instance of the DateTime class, that is not the case.
hormus commentedon Nov 4, 2022
it is not a bug modify does not change timezone, the value is UTC obviously +5 hours in object created America/Lima -05:00
i updated my previous comment inserted the explicit timezone in modify
For me This documentation issue
modify don't change timezone
Expected result:
php 5.3.6 Absolute date/time statements now take effect. Previously, only relative parts were used.
goncons commentedon Nov 5, 2022
@hormus If that is the intended behaviour then there is a "bug" in the documentation or the PHP/DateTime definition of Unix Timestamp for the @ format, bacause the Unix Timestamp is Always in UTC and the @ format is treating it like is a "local" timestamp (if you have to add or subtract the timezone offset).
hormus commentedon Nov 5, 2022
Hi @goncons can you do an example of DateTime::modify which changes the timezone of how it was created?
The Unix timestamp or @ format is the UTC time measurement, if the object uses an immutable timezone (for DateTime::modify) it makes sense to set Unix timestamp without calculating the timezone.
Since exists DateTime::__construct or (DateTime::setTimestamp int) the current use of @ format inside the DateTime::modify function is not to be modified for two reasons 1) to avoid a useless check and 2) It exists since php 5.3.6 the change causes a break
DateTime::__construct — Returns new DateTime object
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).
Epoch time (also known as the Unix time) 1970-01-01 00:00:00
$date1 have UTC timezone and $date2 have America/Lima with same output display and different timezone offset (UTC +00:00 America/Lima -05:00 or -04:00 with DST active)
the maintainer of the date @derickr will decide the desired behavior. I ask for a note for good code practice it is not recommended to enter the timezone as it is ignored by DateTime::modify if you want to change the timezone use DateTime::setTimeZone or if you use @ format use DateTime::__construct
ciaranmcnulty commentedon Dec 19, 2022
This came up in discussion with @nicolas-grekas today.
The only timezone that makes sense is UTC (unless there's some concept of 'timezoned timestamps' out there in the wild I've not come across)
This is presumably why the constructor ignores timezones for these dates:
For me the only logical expectation would be that using
modify()with the same string format would result in the same DateTime, but it does not:Indeed the way the docs are structured, the formats are documented independently of the methods using them, and the relevant page states
The "Unix Timestamp" format sets the timezone to UTC.without anything likenot for modifyTo me this is clearly just a bug and the fix is obvious...
derickr commentedon Dec 20, 2022
The bug is indeed that with
modify()the timezone isn't reset, whereas it should. There is however no "obvious fix", nor trivial fix, for this.The "expected output" from the original report is also wrong though, the output should be:
As the
@format specifically says that the timezone is reset toUTC.Fix phpGH-9891: DateTime modify with unixtimestamp (@) must work like…