I just installed a clean (fresh) copy of Drupal 4.3.0. The system server time is in Pacific Timezone.

I created a new user, and set the timezone for the user to Pacific Timezone (GMT -08:00). The displayed local time was correct (eg displayed "now" as 16:23 - when it was 16:23).

I created an event on the event calendar - set for Saturday, the 8th at 17:00. The event then shows up as Sunday the 9th at 01:00.

I edited my user account and set the user timezone back to GMT (eg GMT +00:00) - even though the specified time is incorrect.

The calendar entry is still incorrect - as the time in the event was set incorrectly in the database. I change the event date and time to the correct time - and now it displays correctly.

I reset my user account timezone back to Pacific (GMT -08:00), and the event displays correctly.

Comments

shane’s picture

shane commented
Title: Timezone issues with 4.3.0 code » Timezone issues with event.module in 4.3.0 code

I just installed a clean (fresh) copy of Drupal 4.3.0. The system server time is in Pacific Timezone.

I created a new user, and set the timezone for the user to Pacific Timezone (GMT -08:00). The displayed local time was correct (eg displayed "now" as 16:23 - when it was 16:23).

I created an event on the event calendar - set for Saturday, the 8th at 17:00. The event then shows up as Sunday the 9th at 01:00.

I edited my user account and set the user timezone back to GMT (eg GMT +00:00) - even though the specified time is incorrect.

The calendar entry is still incorrect - as the time in the event was set incorrectly in the database. I change the event date and time to the correct time - and now it displays correctly.

I reset my user account timezone back to Pacific (GMT -08:00), and the event displays correctly.

Anonymous’s picture

(not verified) commented

My conditions are exactly the same as per shane's post.

I edited events.module and made the following change to

function event_validate(&$node) [line 150]:

/* DSF changed '$node->year) - $GLOBALS['user']->timezone - date("Z")' to
'$node->year) - date("Z")' */

With that change, the time entered for an event stays as entered when the event is posted.

David Finley

sdondley’s picture

sdondley commented

It all boils down to this: times for events should be tied to the location of the event, not the whatever timezone the computer user happens to be in.

The problem would arise in the following situation: Someone lives just east of a time zone "border" and they set the time for their meeting for 6pm in Town X. This user, and Town X, are both in the Unites States, using Eastern Standard Time (EST). Now, the 6pm (18:00) gets stored in the database as 10 (22:00) pm GMT.

But then someone who lives west of the time zone "border," in the Central Standard Time (CST) zone comes along and views the event. He lives in Town Y. The date is fetched from the database and then corrected for Town Y in the CST zone. It reports that the meeting is at 5:00pm (17:00) and not 6:00(pm).

You can duplicate this bug by changing your time zone setting in the "my account" section of your Drupal install.

I see two possible solutions:

1) Next to the start time, have a drop down menu that allows the user to select the time zone where the event will take place.
2) Continue to store the time in the database using GMT.
3) Add a column to the event table to store the timezone
4) When the time is fetched from the database, use the timezone setting from the database and not the user's setting when calculating the start time.
5) Make appropriate adjustments to the code to ensure start times also display the time zone for the event.

OR

1) Avoid adjusting the start time in the first place. This works only if everyone assumes the start time for the event is tied to its location and not to their own particular time zone. I think it's safe to say most people would.

kyber’s picture

kyber commented

Thanks for the suggestion sdondley.
That was just easiest.
Stripped all the gmmktime and gmdate and replaced with mktime and date as well as stripping the +/- user timezone variable stuff from my S.O.'s site. Now everything seems to be fine. No more screwed up breadcrumbs due to code filling out day at midnight greenwich mean time minus timezone. Might be *slightly* confusing to visitors to site, but frankly, I'd rather simply put in that all events are happening at site time (EST) then worry about all that mess. Plus old way was just broken.
Being a month off is far worse than being a few hours off - especially when events are usually all day, or have times specified in event text.

Also have that correction to the year calendar on it.
This year's events
checkitout.

hba’s picture

hba commented

I don't know if this is related: I am experiencing skewed times when I add events that happen a month or two from now. For example I just added an event on 2nd of April at 17:30, but 19:30 was showed afterwards. I had to enter 15:30 to get the event to actually show 17:30. I live in CET (GMT+1 DLT) and use Drupal 4.3.2.

kyber’s picture

kyber commented

Skewed times is probably because you don't have your timezone set correctly. The event adjusts to your timezone settings. What we're having problems with is more the fact that it takes, say, the 0th hour of the 1st day of the month for a calculation, then adds the timezone to it.
If you're at GMT minus X hours, that will result in the month being completely off.
It is for that reason I stripped the timezone calculations, which weren't that helpful anyway. We needed a fixed time for events, and for our site, we've declared that to be site time, EST.

Anonymous’s picture

(not verified) commented

hey kyber!

what about the case when you can't set the timezone information, as in the case of the Anonymous user...how about then. I'm having problems with the Anonymous users seeing the calendar 5 hours ahead of time.

i'm using drupal 4.3.2 and latest stable event.module
my server is in the EST timezone and my users (all anonymous) are also in the EST timezone

what should one look/tweak/reconfigure to get this going?

-erald

kyber’s picture

kyber commented

just remove all:
gmmktime(stuff) - $GLOBALS['user']->timezo
ne;
in event.module and replace with:
mktime(stuff)

mktime will use the server time which realy is less confusing for fixed events.

If you can't manage it, I can generate a patch for you. Guess I could include my little year calendar, too.

Anonymous’s picture

(not verified) commented

kyber!

i grep'ed event.module and there are 11 occourences of gmmktime
however, there are only 3 occourences of gmmktime(stuff) - $GLOBALS'user'->timezoze
and that's what i changed...seems to work so far

i still have to wait for 7:00 P.M EST since that's when the previous problem was starting to 'reveal' itself

thanks for your help
-erald

P.S i still would not mind including your calendar in my site, perhaps having a menu block with a link on the whole year's events :-)

etroja at albunix dot org

Anonymous’s picture

(not verified) commented 
  if (arg(2) === NULL)   {
    $breadcrumbs[] = l($year, "event/$year");
    // No month, display all months
    $day = -1;  // no day
    $output .= '<table id="full-year">';
    for ($i = 1;$i <= 12; $i++)  {
      ($i%3 == 1) && $output .= "<tr>";
      $output .= "<td>";
      $output .= event_calendar('event_calendar_simple', $year, $i, $day);
      $output .= "</td>";
      ($i%3 == 0) && $output .= "</tr>";
      }
    $output .= '</table>';
    }

Here you go, then. Not the prettiest of things, I just outputted all the sidebar calendars. id="full-year" so layout could be tweaked. Haven't bothered to do that yet, but things perhaps like fixing table cell sizes and alignments to make the calendars more even.
BTW, IMO, even the non-localised gmmktimes could be removed. They probably won't cause the bug I was having, but since you are declaring system time to be the event standard time, might as well take them out too. Alternatively, you could leave in all the gmmktimes, and just take out the localisation subtraction. Then all events will be standard on GMT.

Anonymous’s picture

(not verified) commented

kyber thanks again

-erald

killes@www.drop.org’s picture

killes@www.drop.org commented

This is fixed in cvs.

killes@www.drop.org’s picture

killes@www.drop.org commented

I said "fixed".

Anonymous’s picture

(not verified) commented