owncloud server 9 > logtimezone #23134

Closed
StrannikST opened this Issue Mar 11, 2016 · 16 comments

Projects

None yet

10 participants

@StrannikST

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

  1. logtimezone > config.php
  2. 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

@alraban
alraban commented Mar 11, 2016

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.

@HocEman
HocEman commented Mar 11, 2016

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

@schnello

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#

@StrannikST

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);
        }

on

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

@schnello

Thx @StrannikST for the temp solution

@StrannikST

You’re welcome

@Phiber2000
Contributor

I can confirm this issue, too. It is caused by commits d0464bf, 7fce06b.
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!

@PVince81 PVince81 added this to the 9.0.1-current-maintenance milestone Mar 14, 2016
@PVince81
Collaborator
@PVince81
Collaborator

This is the PR in question #18978

@nickvergessen
Contributor

@Phiber2000 looks good, mind turning it into a PR?

@nickvergessen
Contributor

PS: but dont use inline if for something like that.

@Phiber2000
Contributor

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

@MorrisJobke
Member

#23225 was merged

@Steve8291

Thank you for posting the fix for this. It has been driving me insane.

@enoch85
Member
enoch85 commented Mar 26, 2016

Is this backported?

@Phiber2000
Contributor

Yes it is: #23240

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment