Client: Linux: Time stamp issues in "server activity tab"

[poVoq]

Expected behaviour

Should show the correct time of modification ("5 minutes ago" etc.) like it does with the windows client (on different machines).

Actual behaviour

It shows "8 hours ago" for a file changed just seconds ago. The actual time shown in the web interface and the sync. protocol tab is correct though.
It might be related to the specific setup: we have a server set to Manila time UTC+8 and windows clients set to the same time-zone work correctly. The Linux system with the issue is a German language client, but also has the time-zone reconfigured to be UTC+8. Strangely the displayed time is not 8 hours in the future as one would expect for the time zone difference, but maybe the client simply can't display "modified in 8 hours" and thus reverts to "modified 8 hours ago" instead?

Steps to reproduce

1. Install Owncloud server set to UTC+8
2. Install Linux client on a german language Kubuntu system with timezone reconfigured to UTC+8
   

   Server configuration

Operating system:
Ubuntu 14.04
Web server:
Apache
Database:
Mysql

ownCloud version:
8.1.4

Client configuration

Client version:
2.1.1
Operating system:
Linux, Kubuntu 15.10
OS language:
German

Any ideas?

[dragotin]

Are you saying that on both the windows and linux clients, the timezone is configured to UTC+8 but both display a different time string in the activity view?

[poVoq]

Yes, on my colleagues PC running windows and the latest version of the client it is shown correctly, while on my PC running Kubuntu and also set to UTC+8 is is not.

[ckamm]

The only thing I could imagine is related is 3cc9019b3785b8f135e7d4b3e4930a96783d420b and #4439 - maybe the fix for Windows broke linux somehow?

[poVoq]

This is the current time output from the Kubuntu client PC (with "timedatectl" in the terminal):

Local time: Mi 2016-03-02 23:06:49 PHT
Universal time: Mi 2016-03-02 15:06:49 UTC
RTC time: Mi 2016-03-02 15:06:49
Time zone: Asia/Manila (PHT, +0800)
Network time on: yes
NTP synchronized: yes
RTC in local TZ: no

I guess it takes the current system time and adds the +8 instead of taking the UTC time as the base. Then the current time looks like it is 8h in the past.

[ckamm]

@poVoq I wonder what the strings coming from the server are like. Could you start with --logfile log.txt, go to the activity view and then later find the line that looks like

03-02 15:36:51:390 0x1b18c20 activitywidget.cpp:167 *** activities (QVariant(QVariantMap ...

and report the first date string? Also post the date that the matching entry in the activity tab on the server shows when you hover over it.

[poVoq]

I don't have the exact same but I guess this is the equivalent:

03-03 08:25:15:370 0xcaafd0 *** activities (QVariant(QVariantMap, QMap(("date", QVariant(QString, "2016-03-03T00:18:16+00:00") ) ( "file" , QVariant(QString, "/XXX/XXX/somefile") ) ( "id" , QVariant(QString, "248276") ) ( "link" , QVariant(QString, "http://URL/owncloud/index.php/apps/files?dir=XXX") ) ( "message" , QVariant(QString, "") ) ( "subject" , QVariant(QString, "Some User hat XXX/XXX/somefile und XXX/XXX/otherfile erstellt") ) ) ) , -Next entry follows here-

The "server activity" tab doesn't show a date when you hover over the entry, only the file name. In the syncronisation protocol the correct time and date is shown (both in the lines and when you hover over it).

Hmm, seems like there might be a problem with the server time settings?
I also noticed now that one of the windows clients uploading the files had a wrong time setting (UTC -8).

[poVoq]

The server shows this in "timedatectl":

Local time: Thu 2016-03-03 08:48:49 PHT
Universal time: Thu 2016-03-03 00:48:49 UTC
Timezone: Asia/Manila (PHT, +0800)
NTP enabled: yes
NTP synchronized: no
RTC in local TZ: no
DST active: n/a

[ckamm]

@poVoq Thanks for the data so far. So the server reports 2016-03-03T00:18:16+00:00 for that entry. Is that correct? What's the time and date shown in the server's activity view (you should be able to hover over the date text to get the correct time, at least in 8.2.0) and what does the client show (both in sync protocol and server activity)?

I want to know whether this is a client bug (interpreting the server timestamp incorrectly) or a server bug (sending a bad timestamp).

[poVoq]

Ah, in the webinterface?
There the date and time gets reported correctly, i.e. it says for example 2h ago and if you hover over it, the date and time is correct according to the timezone.

[nickvergessen]

I wonder what the strings coming from the server are like.
So the server reports 2016-03-03T00:18:16+00:00 for that entry.

it's ISO 8601. The server stores the timestamp and when you grab the activities, we transform the timestamp into the ISO format. With 2.1.1 the time is wrong for me as well (displayes 1hour ago, although I just triggered the activity), but myself build 2.1 branch works perfect, Linux Mint (Ubuntu based) that is.

[dragotin]

The timestamp needs to be in UTC time spec. I wonder if the +00:00 timezone offset in the example above is correct? The server is UTC+8 if I understood correctly.

[poVoq]

Updated the server to 8.2.2 and the issue remains. Good to hear that with the next client update it might be gone somehow (as @nickvergessen seems to imply).

[ckamm]

@dragotin If the ISO8601 date the server sends includes a timezone spec, why is the call to setTimeSpec(UTC) required? (it shouldn't change anything for @poVoq's case though, since his dates have a +00:00 offset anyway)

[ckamm]

@dragotin I've read Qt code and run some tests and am convinced the setTimeSpec() call is wrong. QDateTime::fromString(ISODate) is what QVariant::toDateTime uses and that parses the offset from UTC correctly. Forcing the timespec to UTC explicitly will break the offset and actually alter the referenced point in time:

t = QVariant("2016-03-03T00:18:16+10:00").toDateTime();
qDebug() << t.toMSecsSinceEpoch() << t.offsetFromUtc(); // 1456928296000 36000
t.setTimeSpec(Qt::UTC);
qDebug() << t.toMSecsSinceEpoch() << t.offsetFromUtc(); // 1456964296000 0

$ date --date="2016-03-03T00:18:16+10:00" +%s000
1456928296000

I'll remove the existing calls to setTimeSpec().

[ckamm]

@poVoq Could I ask you to try again with the latest client nightly? I think the client behaves correclty now, but it didn't look like the fix would help with your problem. The nightlies are found at https://build.opensuse.org/package/show/isv:ownCloud:community:nightly/owncloud-client

If the problem persists, could you do the following?

• pick one activity
• check its exact timestamp in the server (by hovering) and report that
• find the _matching_ entry in the client log file (like you did before) and report that
• report the displayed 'N days ago' message in the client
• report the current system time on the same machine

[dragotin]

I think with @ckamm recent investigation and patches, we can set this to ReadyToTest

[poVoq]

The current Ubuntu 15.10 nightly builds seem to fail since a few days. If it works again I might give it a try.

[mcastroSG]

Hi hi:

Steps executed

1. Set at server UTC+8
2. Install client setting the same TZ UTC+8.
3. Create a text file at ownCloud folder and wait for sync.

Results

At Server Activity tab still the same error. "8 hour(s) ago on ..."

Client Version: Version 2.2.0nightly2016421 (build 1557)
Client OS: Ubuntu 14.04 LTE
Server Version: 9.0.1
Server OS: Ubuntu

TimeStamp at server for the file:
17 Apr 21 19:32 testdateManila2.txt
Client Logs attached:
[https://gist.github.com/mcastroSG/d834700310aecb0c28a22c9e824eb4ff]
At client Server Activity tab:
8 hour(s)

Current time at client machine:
jue abr 21 20:09:59 PHT 2016

Current time at server machine:
Thu Apr 21 20:10:45 PHT 2016

Hope it helps :)

[ckamm]

@mcastroSG I've not been able to reproduce the problem. How exactly do you set the server timezone? I wonder about that because what you are seeing would be correct if only the client timezone was changed.

What I did for testing was update /etc/localtime and restart the client and server.

It seems that even after the change the server timestamps are sent to the client in UTC (with +00:00)

[mcastroSG]

Retested again and seems to be working fine

Client Version: Version 2.2.2.
Client OS: Ubuntu 16.04 LTE
Server Version: 9.0.1
Server OS: Ubuntu

[thomas-mc-work]

I've the same effect on my instance.

Server: debian 8, owncloud 9.1
Client: xubuntu 14.04.5, owncloud client 2.2.2

All time zones set to Europe/Berlin (client OS, server OS, server php.ini). I change a file on the server and the client says changed two hours ago (which is exactly the difference between my time zone and UTC).

When I execute php -r 'echo date_default_timezone_get();' on the server then I get Europe/Berlin. php -r 'echo date("c");' gives 2016-08-10T17:04:30+02:00 - which is exact.