Hello,
I'm getting two different values when I use a timestamp with the
date_create() and date() functions:
echo date_create('@1361240634')->format('Y-m-d');
// output: 2013-02-19
echo date('Y-m-d',1361240634);
// output: 2013-02-18
Is this a known issue?
My timezone setting is set to America/Toronto. System time is set to
2013-02-18. Tested with PHP version 5.3.0 and 5.3.21
__
Raymond
Hi!
echo date_create('@1361240634')->format('Y-m-d');
// output: 2013-02-19echo date('Y-m-d',1361240634);
// output: 2013-02-18
timestamp dates are created with UTC TZ, date() assumes your configured TZ.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
Hi!
echo date_create('@1361240634')->format('Y-m-d');
// output: 2013-02-19echo date('Y-m-d',1361240634);
// output: 2013-02-18timestamp dates are created with UTC TZ,
date()assumes your configured TZ.
I ran into this myself and I personally consider date() assuming your
configured TZ A bug. Timestamps are defined as UTC and the behaviour of
DateTime is correct there, that it always assume UTC. date() should do
the same. But then date() behaviour has been that way since ages
and probably a lot of code out there is assuming the current TZ when
using date().
Hi!
echo date_create('@1361240634')->format('Y-m-d');
// output: 2013-02-19echo date('Y-m-d',1361240634);
// output: 2013-02-18timestamp dates are created with UTC TZ,
date()assumes your configured
TZ.I ran into this myself and I personally consider
date()assuming your
configured TZ A bug. Timestamps are defined as UTC and the behaviour of
DateTime is correct there, that it always assume UTC.date()should do
the same. But thendate()behaviour has been that way since ages
and probably a lot of code out there is assuming the current TZ when
usingdate().--
I'm not sure if I would go so far as to call it a bug, since that is the
intended behavior and developers tend to rely on that. However, the
inconsistent behavior between how date() and DateTime factor timezones
should at least be documented if it isn't already.
What if we added an optional argument to date() that would allow the
developer to specify a timezone, including UTC? The default behavior would
be the same as it is now, so there wouldn't be any BC breakage. Thoughts?
--Kris
Hi!
echo date_create('@1361240634')->format('Y-m-d');
// output: 2013-02-19echo date('Y-m-d',1361240634);
// output: 2013-02-18timestamp dates are created with UTC TZ,
date()assumes your configured TZ.I ran into this myself and I personally consider
date()assuming your
configured TZ A bug. Timestamps are defined as UTC and the behaviour of
DateTime is correct there, that it always assume UTC.date()should do
the same. But thendate()behaviour has been that way since ages
and probably a lot of code out there is assuming the current TZ when
usingdate().
Hi David,
I made a patch for a similar issue here:
https://bugs.php.net/bug.php?id=63615
I wonder if this would fix your issue as well.
I pulled it as a random bug fix, but did note that there is some
discrepancy on whether this is intended behavior or not. I'm with Stas
that we should either fix it and make it consistent, or document why
it isn't.
I ran into this myself and I personally consider
date()assuming your configured TZ A
bug.
The description for date() says "local time/date" => considering TZ is not a bug.
Timestamps are defined as UTC and the behaviour of DateTime is correct there, that it
always assume UTC.date()should do the same.
I rather think DateTime::__construct/date_create were wrongly designed for ignoring the
second parameter. Timestamps specify a uniform reference of time, but just
because you use them doesn't imply you're sitting in any particular TZ.