Let's say, I have a Hosting with default timezone "Europe/Berlin",
And in my extension I want work with UTC, so I am doing:
// Force time zone to UTC
date_default_timezone_set('UTC');
// Then somewhere in extension
var_dump(date_default_timezone_get())// all fine timezone is UTC
$someDate = JDate::getInstance('now -3 day');
var_dump(date_default_timezone_get())// whoot? timezone is Europe/Berlin
It is a bit annoying, and produce unexpected bugs, especially when use external libraries which provide the time data as DateTime, and important to keep timezone in UTC for correct datetime comparison.
so the question, why JDate reset Timezone to Server Timezone instead of previous state?
it was made with purpose or it a
Labels |
Added:
?
|
yeap, which makes JDate more unpredictable,
currently the first call of JDate happens at initialization, by some Deprecation log
Throw it into the 4.0 queue and see what happens I guess. Either way it couldn't be done in 3.x because you'd be removing a static class property that's not marked private (and it's a behavior breaking change, even if it'd be to something that's more correct).
Category | ⇒ | Administration |
Priority | Medium | ⇒ | Low |
Status | New | ⇒ | Confirmed |
@PhilETaylor nope, it is totally different issue,
I tried to fix it there #15696 but got small problem
Status | Confirmed | ⇒ | Discussion |
Status | Discussion | ⇒ | Confirmed |
Build | master | ⇒ | 4.0-dev |
Status | Confirmed | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2020-05-30 14:03:19 |
Closed_By | ⇒ | Fedik |
The static is set based on the first caller to the
JDate
and uses@date_default_timezone_get()
to get the timezone. So it would read whatever timezone is set at that time, and uses that for the reset through the rest of the process.