Closed (won't fix)
Project:
Date
Version:
5.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
28 May 2007 at 14:05 UTC
Updated:
15 Oct 2007 at 04:49 UTC
On one of my servers the date module is reporting the wrong $now time, which i gather it is trying to deduce by subtracting the current UTC offset ( date("Z")) from the current time, however one of the two fails.
I noticed there is another way to achieve this which is via gmmktime()
in date.module replacing any instance with..
- $now = (time() - date("Z")) + $user->timezone;
+ $now = (gmmktime()) + $user->timezone;
seemed to correct all my issues
this will require a little testing on different setups, however it solved it for me!
| Comment | File | Size | Author |
|---|---|---|---|
| date-utc-phpfunc.patch | 1.27 KB | dgtlmoon |
Comments
Comment #1
dgtlmoon commentedmay affect http://drupal.org/node/147386
Comment #2
karens commentedThere should be no difference between time() - date("Z") and gmmktime() so I'm confused about why you would see any difference. time() gives you the server-adjusted time, subtracting date('Z') subtracts the amount of the server adjustment to get it back to GMT time, and gmmktime() gives you a time that has not been adjusted for the server.
Anyway, I just committed the fix for the related problem you noted, let's see if that fixes things before making any more timezone adjustment changes. You can reopen this issue if you think it still applies after updating to the latest code.
Comment #3
dgtlmoon commentedHeya karen
yeh thats just the thing! you're right, you wouldn't expect there by any difference, but check this out
hope this helps
cheers
leigh
Comment #4
karens commentedOK, did some testing and it's a php4 vs php5 thing. I tried comparing time(), mktime() and gmmktime() on both php4 and php5.2 in Windows on a server set to a timezone that is -500 and got different results.
In php4 everything behaved as I expected -- gmmktime() was different than mktime() by the amount of the server offset. In php5.2 gmmktime() and mktime() and time() all return the same value -- they all completely ignore the server offset.
I did this in a simple 2 line script that had nothing else on it, so it had nothing to do with any Drupal settings, just my server timezone and the out-of-the-box php setup.
This is going to take some more investigation, but maybe this is behind some of the squirrely timezone problems that always seem to re-appear in dates and events...
I suspect it has to do with the new timezone handling that started with php 5.2 and that the results would be different in 5.0 or 5.1. Can you confirm what version of php you're using?
Comment #5
dgtlmoon commented5.2.0 on here
have seen this problem on 5.2.1 too
Comment #6
karens commentedI did some more testing and found something more -- the difference between mktime() and gmmktime() in php 4 and php 5 is only the way they handle things when they get no arguments. If you give them any values at all, they behave as you would expect.
Anyway, that is on Windows, what OS are you using?
Comment #7
dgtlmoon commenteddgtlmoon@eight:~$ php -v
PHP 5.2.0-10+lenny1 (cli) (built: May 26 2007 08:23:53)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2006 Zend Technologies
same for the apache module too
debian gnu linux
Comment #8
karens commentedSee more of the results of my research at http://groups.drupal.org/node/4838. Not sure yet exactly what fix I will try.
Comment #9
dgtlmoon commentedexcellent research! let me know if you need any more tests done
Comment #10
karens commentedI'm not going to use this patch because of the problems uncovered, instead the next version of the date module is going to quit using gmmktime() altogether.
I don't think there's anything specific to be done in the current version. The latest current version has a variety of workarounds committed.
Comment #11
dgtlmoon commentedok - but ive also had issues using time() instead of gmmktime() when i pass the time to the format_date