I always thought "clock" calculates correct time using server system-time and locale-settings, but it seems not to be true. "Clock" takes local (webclient) system-time! System-time on my local desktop-PC drifted 5min off, and I see exactly this time when I connect to my web-site (where system-time is correct, I checked it). So it is the same time I see when I look into right bottom corner of my windows-desktop. And different clients get different time (as I verified right now, connecting to my website with desktop-PC and notebook)...

Moreover, it completely messes time when local system timezone is incorrect. If my locale-settings in drupal profile are UTC+2 but my local desktop (from which I connect to server using web-client) has locale UTC+1, web-site displays time 1 hour off...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tstoeckler’s picture

What you describe is the wanted behavior for the "Local time zone" time zone type. It should not be that way for any other type. Could you elaborate exactly how you have configured your clock? Even more helpful would be a screenshot of the configuration form. Thanks!

Jarry’s picture

My website has default timezone UTC with user configurable time zones enabled (/admin/settings/date-time). I do not know what you mean with "clock" configuration, there is not much to configure:

languages: all
block title: Date&Time
Time Zone Settings: user time zone
Date format settings: medium
"use javascript to continuously update the clock" is activated
Custom visibility settings: Users cannot control whether or not they see this block.
Show block for specific roles: nothing selected (all)
Show block on specific pages: Show on every page except the listed pages (none listed)

Weberver itself has clock runninig in UTC-zone syncing with a few stratum-1 ntp-servers. When anonymous users connects to my web, what they can see is time dependening on their desktop time. Right now, on my desktop is 20:26 (UTC+2), website shows 18:26 (should be UTC as default time for anonymous), but when i issue "date" in ssh-console connected to the server I see 18:31.

When I create some content (i.e. coments), they have correct create-time (18:31) although clock-block on the main webpage still shows 18:26. This is really strange...


One more interesting thing I discovered: When I load the homepage in IE8, for about 0.2-0.3s I see correct server time (like 18:06) in clock-block, but it is then quickly changed to my desktop (web-client) time (i.e. 18:01). In Firefox only incorrect desktop time (18:01) is shown from beginning. Or it is switched so fast that I do not see it changing...

tstoeckler’s picture

Hmm... so I just checked on my site, and I am not having that problem. That doesn't mean it's not a legitimate bug, but I guess we'll have to dig a little deeper.

From the way you describe that it apeears correctly at first, for a short period of time, it seems that the problem might be related to the JavaScript handling. Could you try disabling JavaScript in your browser (I know that is possible for Firefox not sure for IE)? Even more awesome would be if you could check Firebug for any JavaScript errors/problems. (If you don't have Firebug installed/configured yet, just ask, I'm glad to help.)

Jarry’s picture

I did what you recommended: installed "NoScript" addon for Firefox, blocked scripts for my domain and loaded my website. Guess what?

Time shown by clock-block is correct! It is now the same time I see when I connect to my web-server with ssh and issue "date" (system clock is runing in utc timezone, as well as webserver). It is not my "desktop-time". Of course, the only disadvantage now is that time does not get updated. But whenever I reload webpage, correct time is shown. When I allowed scripts on my web, again incorrect (local desktop) time is shown.

I do not know how to work with Firebug, but the only suspicious message I found is:
Timestamp: 15-Apr-12 19:39:10
Error: Permission denied to access property 'document'
Source File: http://***/sites/default/files/js/js_ba144aa1dcc366a90506a62df2964427.js
Line: 3003
Function: formatDate
File: js_ba144aa1dcc366a90506a62df2964427.js

tstoeckler’s picture

Well, then I guess we have it almost pin-pointed. In order to know exactly where that error happens you would need to disable CSS aggregation on your Performance page and then look at that error again. Then we should know the exact line number in clock.js.

Jarry’s picture

Actually no relevant error has been detected. The one I mentioned above is some problem with my theme. I switched to garland, and this error dissapeared. But problem with clock-block remain: if js is blocked, I get correct server-time (website-time), but of course it is updated only when I reload page. If in web-browser I allow scripts, incorrect time is displayed (desktop-time of web-client, which I intentionally left 5min off correct time)...

sepehr.sadatifar’s picture

Status: Active » Needs review
FileSize
815 bytes

I've made patches against 6.x-1.x , 7.x-1.x and 7.x-2.x.
7.x-2.x patch is tested and works, but I don't have time to test two other patches. hope them work :)
attached file is 6.x-1.x patch

sepehr.sadatifar’s picture

7.x-1.x patch
(sorry I didn't know should attach 7.x patches in this issue or create another issue for 7.x )

sepehr.sadatifar’s picture

7.x-2.x patch

tstoeckler’s picture

Alright, I'll try that out thanks. Last time I checked I could not reproduce the error, but the patch looks like it makes sense. We'll see. Thanks again for the patch!

tstoeckler’s picture

Version: 6.x-1.7 » 7.x-2.x-dev
Status: Needs review » Fixed

Finally got around to committing this. Thanks, you guys!

This only applies to 7.x-2.x, unless I'm severly mistaken. So marking fixed.

http://drupalcode.org/project/clock.git/commit/8c95a179e3b3271f86aa3e804...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

dmadruga’s picture

Version: 7.x-2.x-dev » 7.x-1.x-dev
Issue summary: View changes
Status: Closed (fixed) » Active

I've just tested the patch to 7.1.x and the problem still exists.