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!

CommentFileSizeAuthor
date-utc-phpfunc.patch1.27 KBdgtlmoon

Comments

dgtlmoon’s picture

karens’s picture

Status: Needs review » Fixed

There 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.

dgtlmoon’s picture

Heya karen

yeh thats just the thing! you're right, you wouldn't expect there by any difference, but check this out


dgtlmoon@eight:~$ cat test.php
<?

print (time() - date("Z")) + $user->timezone."\n";
print   (gmmktime()) + $user->timezone."\n";
?>

dgtlmoon@eight:~$ cat test.php|php
1182778658
1182814658

hope this helps

cheers

leigh

karens’s picture

Status: Fixed » Active

OK, 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?

dgtlmoon’s picture

5.2.0 on here

have seen this problem on 5.2.1 too

karens’s picture

I 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?

dgtlmoon’s picture

dgtlmoon@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

karens’s picture

See more of the results of my research at http://groups.drupal.org/node/4838. Not sure yet exactly what fix I will try.

dgtlmoon’s picture

excellent research! let me know if you need any more tests done

karens’s picture

Status: Active » Closed (won't fix)

I'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.

dgtlmoon’s picture

ok - but ive also had issues using time() instead of gmmktime() when i pass the time to the format_date