echo date("H:i:s"); echo "<br />";
    date_default_timezone_set('Pacific/Auckland');
    echo date("H:i:s"); echo "<br />";
    $db = JFactory::getDbo();
    echo date("H:i:s"); echo "<br />";
    $db->setQuery("select * from #__content limit 1");
    $cats = $db->loadAssocList();
    echo date("H:i:s"); echo "<br />";

Result:

20:22:23
08:22:23
08:22:23
08:22:23

Can't confirm that JDatabase changes timezone

@pdoolz can you test the code above from @fruppel please - do you still have an issue

I have the same problems.
I also tried to change the date directly in MySQL, what actually doesn't work also.

It looks like Joomla resets the timezone each query.

$db->execute( "SET time_zone = 'Europe/Moscow';"); // server normally accepts this. Checked in MySQL server directly. Time changes.
$db->setQuery("SELECT @@global.time_zone, @@session.time_zone;");
$db->execute();
$rows=$db->loadAssocList();
echo json_encode($rows);

Result:
[{"@@global.time_zone":"SYSTEM","@@session.time_zone":"SYSTEM"}]

Notes: SYSTEM timezone is other than 'Europe/Moscow'.

Joomla! 3.4.5 Stable [ Ember ] 22-October-2015 21:30 GMT

I think it is caused by JDate::getInstance() behavior, JDate::getInstance() caches the date objects (by date key), and if at some point of time was requested cached date, but with different timezone, then cached object changes to requested timezone, and you get result exactly as you described

it not a it is feature

JDate itself isn't caching anything. JFactory::getDate() does cache by the
time string plus timezone and always returns a clone.

On Saturday, January 30, 2016, Fedir Zinchuk notifications@github.com
wrote:

I think it is caused by JDate behavior, JDate caches the date objects (by
date key), and if at some point of time was requested cached date, but with
different timezone, then cached object changes to requested timezone, and
you get result exactly as you described

—
Reply to this email directly or view it on GitHub
#8958 (comment).

sorry, ignore whole my message,
@mbabker is right.

but, cloning JDate seems does not clone $tz property of JDate, so if TimeZone object in use somewhere, and changes at some point of time, it still can cause such issue.

in theory, for fix it, need to add __clone() to the JDate:

function __clone()
{
  $tz = clone $this->tz;
  $this->setTimezone($tz);
}

Just in case, a workaround I used by now is taking the timezone from user
(or config) and bussing it as a variable to the stored procedure which
executes set time zone and makes a select.

воскресенье, 31 января 2016 г. пользователь Fedir Zinchuk написал:

in theory, for fix it, need to add __clone() to the JDate:

function __clone(){ $tz = clone $this->tz; $this->setTimezone($tz);}

—
Reply to this email directly or view it on GitHub
#8958 (comment).

С уважением, Ключко Никита

Just tested something and dunno if this is related.
Maybe i'm missing something but both constructor(JDate and Datetime) dont return same result with a timezone given;

To demonstrate, use this:

$d1 = new JDate('2016/08/02 16:30:00',new DateTimeZone('Europe/Paris'));
$d2 = new DateTime('2016/08/02 16:30:00',new DateTimeZone('Europe/Paris'));
echo '<pre>'.$d1->format('d/m/Y H:i:s (e)').'</pre><pre>'.$d2->format('d/m/Y H:i:s (e)').'</pre>';

02/08/2016 14:30:00 (GMT)
02/08/2016 16:30:00 (Europe/Paris)

JDate is a quirky beast and the format() method default signature goes against the parent DateTime object. By default it formats dates to GMT and you have to pass a second parameter to get the date converted to the "local" timezone (so $d1->format('d/m/Y H:i:s (e)', true); should give you the date in the right timezone).

Thx for explanation @mbabker , i missed this param...

Can we close this?

I'd say yes as it's expected behavior (debatable whether it's correct depending on who you ask). The JDate constructor changes the system timezone to UTC and it is recommended to use the JDate class for date/time operations in the CMS environment instead of the procedural date functions or the DateTime class (the main thing JDate offers is a standardized timezone for date/time values and translatability of the strings that come with it).

Closed as expected behaviour

Hi,

Could somebody please test the code below and let me know why the dates returned are different ?

`
$mainframe = \JFactory::getApplication();
date_default_timezone_set($mainframe->getCfg('offset'));

print_r(date('Y-m-d H:i:s'));
\JDatabase::getInstance();
print_r(date('Y-m-d H:i:s'));
`
Joomla config server timezone is set to UTC, server timezone using print_r(date_default_timezone_get()); is Europe/Berlin, what JDatabase does is that it reverts the new set timezone which is the one in Joomla config (UTC) to the server's default.

Thanks!

1. No part of the database API touches the system timezone (either read or write), so if the date is getting changed then there is something else not part of Joomla core making the change.

2. All places in Joomla core which do change the system timezone immediately reset that value. The changes are done to standardize time operations to UTC (or a user configured timezone when converting values). So at the worst the timezone has changed for 3 or 4 lines of code which don't even have an integration point to hook into.

3. The database API does log statements. When the logger API creates a JLogEntry object, it creates a new JDate object. As explained earlier, the JDate constructor does change the system timezone to create an object standardized on the UTC timezone. But also immediately resets the timezone. It does this by creating a DateTimeZone object based on the default system timezone via date_default_timezone_get(), however, this function call also has error suppression in front of it. So if the date_default_timezone_get() call fails, the system timezone won't be known and the time can't be correctly reset. This is indicative of a PHP configuration error on your local platform.