WebUI timestamps not matching nzbget.log timestamps

Get help, report and discuss bugs.
Post Reply
weekender
Posts: 35
Joined: 07 Aug 2014, 19:04

WebUI timestamps not matching nzbget.log timestamps

Post by weekender » 29 Oct 2017, 05:41

Hey Hug,

I know you're prolly aware of that.
From the looks of it, the webui seems to always show UTC timestamps.

Is there a way to have the webui match the timestamps from the logs?
The timestamps in the logs seem to match my system's localtime.

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: WebUI timestamps not matching nzbget.log timestamps

Post by hugbug » 29 Oct 2017, 07:06

There is option "TimeCorrection" to adjust time in log but if you already have correct time in log but wrong time in webui that means the time zone is misconfigured on computer where nzbget is running.

weekender
Posts: 35
Joined: 07 Aug 2014, 19:04

Re: WebUI timestamps not matching nzbget.log timestamps

Post by weekender » 29 Oct 2017, 09:07

hugbug wrote:
29 Oct 2017, 07:06
There is option "TimeCorrection" to adjust time in log but if you already have correct time in log but wrong time in webui that means the time zone is misconfigured on computer where nzbget is running.
I'm running Nzbget on Ubuntu 16.04 and my timezone seems to be set properly. "TimeCorrection" is set to 0.
Looked at /etc/localtime and /etc/timezone and they're both in check. Unless time on Ubuntu also has to be configured some place else :?

Code: Select all

$ date
Sun Oct 29 02:02:11 PDT 2017
I'm guessing the "date" method used in webui just defaults to UTC somehow?

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: WebUI timestamps not matching nzbget.log timestamps

Post by hugbug » 29 Oct 2017, 09:31

The browser runs on the same machine?

weekender
Posts: 35
Joined: 07 Aug 2014, 19:04

Re: WebUI timestamps not matching nzbget.log timestamps

Post by weekender » 29 Oct 2017, 10:07

hugbug wrote:
29 Oct 2017, 09:31
The browser runs on the same machine?
Forget it Hug, after you mentioned "browser", I actually accessed Nzbget with a different browser and the webui timestamps are fine.
I have many addons on my Firefox browser so it's prolly messing up the javascript stuff used in the webui.

Sorry for wasting your time, I've been at it for hours and am now almost bald from pulling my hair out :lol:
Last edited by weekender on 29 Oct 2017, 10:18, edited 1 time in total.

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: WebUI timestamps not matching nzbget.log timestamps

Post by hugbug » 29 Oct 2017, 10:15

More details: nzbget internally stores timestamps in UTC. These UTC values are then transferred to webui. Webui uses JavaScript object/function "Date", which takes timestamp in UTC and returns local time.

That means that your browser is in a different time zone than you. Try another browser.

Try this: in web-browser open address http://192.168.1.3:6789/jsonrpc/log?=0&=5 (adjust IP), as result you get last five messages from nzbget log. Copy the time field from one message and convert it to human readable time on https://www.epochconverter.com. Is the time correct there?

weekender
Posts: 35
Joined: 07 Aug 2014, 19:04

Re: WebUI timestamps not matching nzbget.log timestamps

Post by weekender » 29 Oct 2017, 10:20

hugbug wrote:
29 Oct 2017, 10:15
More details: nzbget internally stores timestamps in UTC. These UTC values are then transferred to webui. Webui uses JavaScript object/function "Date", which takes timestamp in UTC and returns local time.

That means that your browser is in a different time zone than you. Try another browser.

Try this: in web-browser open address http://192.168.1.3:6789/jsonrpc/log?=0&=5 (adjust IP), as result you get last five messages from nzbget log. Copy the time field from one message and convert it to human readable time on https://www.epochconverter.com. Is the time correct there?
Looks like you posted this while I was editing my reply.
See the reply above your post. And yes you were right, using a different browser was the key! Thanks man!

Edit: real source of problem was in Firefox, "privacy.resistFingerprinting = true" in about:config. Setting it back to its default "false" value solved my problem.

Post Reply

Who is online

Users browsing this forum: No registered users and 59 guests