By David Sewell on
Is there a way to configure a Drupal site so that it uses a different GMT offset (i.e. time zone) than the computer it is on? My situation: I administer a Drupal site whose users are located in the Eastern U.S. time zone (GMT-5), but it is hosted on a server in California (GMT-8). That causes problems for both timestamps and things like the Event module, where it is necessary to use California times when posting an event in Virginia! Of course individual users could set their time zones to California, but that is not an ideal workaround.
Is there a better solution?
Thanks,
David Sewell
Comments
Additional explanation
Here's an example of the problem. Let's say I want to create an event in the Event module that will occur in Virginia (GMT-5) at 1900 hours. When I create the event, I must enter the time as 1600 hours (California time/server time). Then, because my user profile has me in Virginia's time zone, I will see the event listed for 1900 hours. But an anonymous user will see the event listed for 1600 hours, because Drupal assumes that an anonymous user is in the same time zone as the server.
The groupware program PHProjekt has a configuration option to address the case where there is a time zone difference between server and (default) user. But I don't believe Drupal has an option like this?
I've got the same problem and
I've got the same problem and searched everywhere I could to find a solution. All I found was mention of a patch for it in a rather old thread but nothing about where to find it. I commented asking for info but have never received a reply.
This pops up in various areas. I first noticed that when you're making a post, the time shown isn't local time but when you submit the post, it will display local time.
Then a member said she kept entering her birthday (in her profile) as February 7th but it kept changing to the 6th. She was really confused about it with good reason!
Seems it came up somewhere else, but I sure can't remember hehee! I hope someone answers this one - it sure is irritating.
Keith aka pianoman
You can try modifying common.inc
function format_date($timestamp, $type = "medium", $format = "") {
global $user;
$timestamp += ($user->timezone) ? $user->timezone - date("Z") : 0;
to
function format_date($timestamp, $type = "medium", $format = "") {
global $user;
$timestamp += ($user->timezone) ? $user->timezone - date("Z") : 36000;
I've used 36000 because that's GMT +10. Have a look what the equivalent of your GMT is and just replace that.
HTH
mC
Although I'm not entirely sur
Although I'm not entirely sure here, it seems to me that this mod would affect the time/date displayed in a submitted post or comment, not on the post/comment editing page or profile edit page, which is where the difficulty lies. Once submitted, the problem no longer exists - at least in the case of posts or comments. However, the birthday issue is still a problem.
If I'm understanding the function correctly, wouldn't it change the displayed date everywhere except in those editing areas? And in fact, wouldn't it be incorrect - wouldn't it be, in the case you gave, +10 hours from the user's local time?
However, this might be where the solution lies:
http://drupal.org/node/view/3486
Keith aka pianoman
the problem is the date() functions...
...in the event module.
It calls for the date off the server.
I struggled over this for a long time shortly after I discovered Drupal.
I had a guy email me this link:
http://www.phpbuilder.com/mail/php-general/2002011/1176.php
which suggested:
putenv("TZ=PST8PDT");
I changed the TZ variable to CST6CDT (I figured if PST was 8... Central would be 6), added it to the top of index.php, and everything was fixed.
Hope this helps.
-Skip
unacceptable
Its more then a year later and this problem still exists as far as I can tell. It turns what could be a fairly professional product into hardly more then an amateurish blog system.
It should be pointed out that people live in time zones, not in GMT offsets. The offsets change twice a year in most of the world. It creates all sorts of problems with the Event module especially.