Core: owncloud server 9 > logtimezone

Created on 11 Mar 2016 · 17Comments · Source: owncloud/core

Hello. Help please , updated to 9 owncloud server. Now it does not work logtimezone (config.php). And now fail2ban not bans . Since time does not match. What to do?

Steps to reproduce

logtimezone > config.php
php.ini date

Expected behaviour

When recording a log does not change the time zone

Actual behaviour

When recording logs must change the time zone

Server configuration

Operating system:
ubuntu server 14.01
Web server:
apache2
Database:
mysql
PHP version:
php 7
ownCloud version: (see ownCloud admin page)
owncloud server 9

core regression sev2-high

Source

StrannikST

Most helpful comment

@nickvergessen I'll create the PR in some minutes, using if-else blocks in code.

Phiber2000 on 14 Mar 2016

👍2

All 17 comments

I can confirm that I'm seeing the same thing here. The LogTimeZone setting in the config.php does not appear to affect the actual timestamps in the logs, which breaks fail2ban.

alraban on 11 Mar 2016

I am seeing the same behavior. Log time stamps do not reflect the timezone set.

HocEman on 11 Mar 2016

I can confirm the problem also.

{"reqId":"rRw4WfPoRl0DscSMS8mb","remoteAddr":"185.65.xxx.xxx","app":"core","message":"Login failed: 'User' (Remote IP: '185.65.xxx.xxx')","level":2,"time":"2016-03-12T09:30:18+00:00"} root@nas:/home/nas# date Sat Mar 12 10:30:51 CET 2016

root@nas:/home/nas# cat /var/www/owncloud/config/config.php | grep time 'logtimezone' => 'Europe/Berlin', root@nas:/home/nas#

schnello on 12 Mar 2016

I decided this issue . One possible solution is: file owncloud \ lib \ private \ log \ owncloud.php replace strings

$time = DateTime::createFromFormat("U.u", number_format(microtime(true), 4, ".", ""), $timezone);
        if ($time === false) {
            $time = new DateTime(null, $timezone);
        }

$time = new DateTime(null, $timezone);

StrannikST on 12 Mar 2016

👍1

Thx @StrannikST for the temp solution

schnello on 12 Mar 2016

You’re welcome

StrannikST on 12 Mar 2016

I can confirm this issue, too. It is caused by commits d0464bf7724480d18d1f0b881acf83849d83b72d, 7fce06b3f32ec564f129bf2a361d6ee37096e03b.
The fix by StrannikST from above reverts these commits.

Troubleshooting

The problem seems to be caused by the function 'DateTime::createFromFormat', which has the following constraint:

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

Source: https://secure.php.net/manual/en/datetime.createfromformat.php

Fix proposal

Remove the timezone parameter from "DateTime::createFromFormat" because it has no effect and just set timezone afterwards.

$time = DateTime::createFromFormat("U.u", number_format(microtime(true), 4, ".", ""));
$time ? $time->setTimezone($timezone) : $time = new DateTime(null, $timezone);

That's it!

Phiber2000 on 14 Mar 2016

CC @schnidrig