Major timezone bug in event module

I just want to confirm the bug. When Configurable time zones is not enabled the event always reverts to Use the Events time Zone. It also set every event 1 hour earlier than the time entered by the user. When I enabled configurable time zones and edited the event settings to use the site time zone it fixed the hour discrepancy. I then disabled configurable time zones and it reverted to "use event timezones" and had the hour discrepancy again.

i had 2 sites using 4.6; times in events were working correctly. both sites set to NONconfigurable time zones.

after upgrade to 4.7.2, event times display 1 hour early. that is, if i enter a start time of "6pm" the display is "5pm".

when i check the unix timestamp in phpMyAdmin, i find the time is also off by 1 hour: the timestamp is the same at what is being displayed and not what was entered (the start timestamp is 0000gmt, which is 5pm my time -- it should be 0100 gmt).

i remember this exact problem with an earlier version of 4.6; imagine my dismay to see it reappear in 4.7!

This may sound like a dumb question, but what timezone are you in? I'm using site timezone settings (rather than user or input) and am in the PST (GMT-8) zone and have exactly this problem.

Could this be related to a daylight savings time problem...? (off by 1 hour...)

I found this DST discussion thread: http://drupal.org/node/11077
(I see that Drupal 4.7.x doesn't deal with DST issues..)

I can't see how the event start and end times are being modified (-1hour) - it's not all that clear to me how the code works... and without a real PHP debugger, it's tedious at best. I'll keep digging.

I've done some digging: when using the jscalendar extensions (as I am), the format strings used to populate the event input forms are incorrect: they use 'm' for minute, which is really month! Should be 'i' according to this page:
http://us3.php.net/manual/en/function.date.php

function event_form_alter($form_id, &$form) {
/* ... */
    case $type .'_node_form':
/* ... */
        if (module_exist('jscalendar')) {
          $form['start_date'] = array(
            '#title' => t('Start Date'),
            '#type' => 'textfield',
            // NOTE: incorrect format string below
            '#default_value' => _event_date('Y-m-d H:m', $node->event_start ? $node->event_start : _event_user_time(), $node->start_offset), 
            '#attributes' => array('class' => 'jscalendar'),
            '#jscalendar_ifFormat' => '%Y-%m-%d %H:%M',
            '#jscalendar_showsTime' => 'true',
            '#jscalendar_timeFormat' => variable_get('event_ampm', '0') == 0 ? '24' : '12',
            '#size' => 19,
            '#maxlength' => 19,
            '#weight' => -15,
            '#description' => t('YYYY-MM-DD HH:MM'),
            );
          $form['end_date'] = array(
            '#title' => t('End Date'),
            '#type' => 'textfield',
            // NOTE: incorrect format string below
            '#default_value' => _event_date('Y-m-d H:m', $node->event_end ? $node->event_end : _event_user_time(), $node->end_offset),  
            '#attributes' => array('class' => 'jscalendar'),
            '#jscalendar_ifFormat' => '%Y-%m-%d %H:%M', 
            '#jscalendar_showsTime' => 'true',
            '#jscalendar_timeFormat' => variable_get('event_ampm', '0') == 0 ? '24' : '12',
            '#size' => 19,
            '#maxlength' => 19,
            '#weight' => -14,
            '#description' => t('YYYY-MM-DD HH:MM'),
            );

So, change the incorrect formats to:
'Y-m-d H:i'

And this fixes the described problems (incorrect time values in input fields) when jscalendar enabled. Doesn't do anything for the 1-hour offsets I'm seeing on my installation (also described by others, above.)

If I get a chance, I'll work up a patch file.

The other problem (the -1 hour error) seems to be due to an inconsistency in the way that the timezone adjustment is calculated when using 'site' timezones.

I think I've found a solution; I'd like people to review the patches and comment.

I've attached patch 1 of 2, against the Drupal-4-7 branch (Aug. 23, 2006) for event_timezones.inc to add a helper function, which is used in the forthcoming patch to event.module. Again, this is patch 1 of 2.

/**
 * Get a DST-adjusted timezone adjustment for a given timezone offset and timestamp. If 
 * there is no known zone or no offset, will just return the value of 
 * $original_offset.
 * @param $original_offset The original, unadjusted timezone offset.  Must be one 
 * of the offsets valid for event_timezone_map() function, and the map used 
 * therein.
 * @param $the_timestamp The timestamp of the event - this is used to 
 * determine whether the offset needs to be adjusted for DST.
 * @return 
 */

function event_get_dst_adjusted_offset($original_offset, $the_timestamp) {
    $zid = event_timezone_map($original_offset);
    if ($zid) {
        return event_get_offset($zid, $the_timestamp);
    } else {
        watchdog('event', "Unable to find timezone for offset $original_offset - is site timezone setting valid? ");
        return $original_offset;
    }
}

Patch 2 of 2. This one is for event.module Drupal-4-7 (1.183.2.8) dated 8/23/06.

This patch is intended to correct the one-hour offset problem when events are created/edited using 'site' timezone offsets. (non-customizeable timezones, and events are set to use site timezone.)

Please review and comment.

Clarification: My patch 1 of 2 is against the drupal-4-7 label version of event_timezones.inc, with a version string of 1.4.2.3 2006/05/22 13:35:07. (Updating the comments for the original patch upload)

It appears that the latest 4.7.x release of the event module has the fix for the jscalendar issue I mentioned in my comment # 5, above. So, ignore that comment, please, just get the latest 4.7 distro (event.module 1.183.2.8)

Bump - anyone care to comment on the patches described at:

http://drupal.org/node/78572#comment-129620

and

http://drupal.org/node/78572#comment-129621

Mainly curious about the timezone handling problem; is this fixed/addressed elsewhere, and if so, where?

inactivist,
I have the exact same issue. I applied patch 1 of 2 (http://drupal.org/node/78572#comment-129621) but this did not fix the problem. Will look into it further.

That should read 'patch 2 of 2', sorry.

Sorry I didn't really describe the issue properly. I am having the exact two same issues as Ramdak describes in the inital bug report. I have applied patch 2 of 2 submitted by inactivist but this did not seem to remedy the problem. Still looking :)

If you applied patch 2 of 2 only then you will encounter errors. Patch 2 relies on a new function introduced in patch 1 in order to work properly.

So, if you applied only patch 2, I'm puzzled if you haven't encountered any errors.

hmm no errors no... ill patch part 1 now.. cheers for the heads up

Unfortuantly patching the other half did nothing for me either. Is your patch specific to American timezones?

These patches do not address both the issues described in the intial patch and, for me at least, they do not fix the 1 hour time difference.

Hm... well, on my system (http://amadorable.com/event) it's all working fine. I wonder why?

In any case, since it all seems to work for me, I don't know when I'll be able to investigate further... anyone else care to take a stab at it?

Changing from patch (code needs work) to active

I forgot to mention: amadorable.com is set to GMT-7

I must say it is a strange bug. I am +8 GMT and I am starting to wonder if it is a daylight saving issue. Does the event module try to apply daylight saving to timezones?

Last time I looked at the code, I saw no DST handling. Drupal core has no notion of DST, either, from what I've read.

No, the problem I saw was due to an inconsistency in the event module's handling of timezones as described in my patches. It's possible that I've missed something, or misunderstand the way this should work, though.

Feel free to create an account on http://amadorable.com and visit http://amadorable.com/event and set up a few dummy events - it all works on my site, at least as far as I can see. Or have I missed something?

I'm perfectly willing to post my patched modules if someone wants to examine them.

-Mike

Oops, my bad, yes, the event module does use DST info from the tables in event_timezones.inc file. So, if there are any errors in the timezone information in those tables, then perhaps that could cause a problem. Perhaps the logic if failing for +8 GMT?

Also, the module behavior depends on how you have your site set up - adjustable timezones, etc. will alter the behavior of the event and basicevent module, so it's possible that the code in my patches isn't being executed on your site... how do you have timezones configured? Site-wide, user-adjustable, etc?

-Mike

http://amadorable.com is set up for site-wide timezone (no user-configurable timezones.) Which may be why my patches are effective on my site, and your site did not crash when you applied patch 2 (http://drupal.org/files/issues/event.module_44.patch) only: patch 2 is executed only if site-wide timezones are set (no user-adjustable timezones.)

Is your site set to allow user-configurable timezones (Admin->Settings->Date Settings->Configurable time zones) ? My patch does not apply to that configuration, as this bug report was for site-wide timezones...

-Mike

Hi mike.. Thanks for the info. My site is setup in the same way as yours (sitewide timezone, no user config) which makes me even more certain it is a daylight saving issue. Here in Perth (GMT+8) we don't have daylight saving at all, but I would wager other regions that fall under +8 do, so i will checkout event_timezones.inc. Thank you for your help.

I am an idiot , I am an idiot, I am an idiot.... Someone had switched the timezone to GMT+9.. and they have daylight saving of -2 so thats why.. Thanks for your help mike.. That bit of info eventually led to me finding the most obvious error ever :) sorry to waste your time but thanks once again :D

upon further reflection i still have this issue.. this is making a fool of me :D anyway it is most definatley a DST issue so i will get to the bottom of it

I have this problem as well. Applied the patches - no joy.

I have a wholly separate problem with jscalendar, though; if I use jscalendar and pick 21:00 for the time, then the time gets set to 09:00, which (still) displays as 08:00.

So in other words, not only do I still have the one hour offset problem, but when I use jscalendar, 12 hours are subtracted from the time in the input field if the hours are greater than 12. I think the problem is maybe around line 1513 someplace...

    $hour = $node->{$prefix . 'hour'};
    if (variable_get('event_ampm', '0')) {
      if (($node->{$prefix . 'ampm'} == 'pm') && ($hour != 12)) {
        $hour += 12;
      }
      elseif (($node->{$prefix . 'ampm'} == 'am') && ($hour == 12)) {
        $hour -= 12;
      }
    }

(pardon my php tags, I just wanted indenting and pretty printing. this chunk of code is not surrounded in <?php ?>.)

That snippet begins on line 1515 in my event.module file (post-patches.) At a glance it looks like the hour is set from the form field, then "adjusted" based on the event_ampm value. If event has not been instructed to use am/pm (?) then it modifies the value. But first, it does some jscalendar-only date parsing, because if you don't have jscalendar then you don't get this data from the same kind of field(s) right? This is the first time I've ever dug into this module's internals.

I went and changed my event settings preference to specify 24 hour time, and now while I'm still off by an hour on display, it's no longer "correcting" jscalendar dates after 12pm to something 12 hours previous.

Also one might consider looking at this code:

$timestamp = mktime(substr($this_date, 11, 2), substr($this_date, 14, 2), substr($this_date, 17, 2), substr($this_date, 5, 2), substr($this_date, 8, 2), substr($this_date, 0, 4));

jscalendar doesn't return seconds. Is this so that the user can enter them manually? This line could equally be the following code:

$timestamp = strtotime(str_replace('-','/',$this_date));

I don't know which is more efficient. I'm leaving it alone since the existing code works, but I thought it was amusing.

Anyway my biggest problem with jscalendar is this 12 hour thing. One last recap for clarity: If I have event set to display 24 hour times, then any event time I put in with jscalendar that is past 12 pm is decremented by 12 hours, and saved this way. Not just displayed, but saved. But I'm still having the problem with the 1 hour display offset of events.

My system is currently set to PDT. My site is currently also set to PDT (-0700). This is the selection under date settings that shows the correct time. This is great, but now I'm going to have to change this setting manually? I know this is a drupal and not an event.module problem, but it seems kind of stupid to me when my system is sitting around figuring out DST for me. Obviously drupal (or php, or whoever) is somehow figuring out the proper time etc.

At this point I'm just confusing myself so I'm going to stop, but suffice to say that I am still having this off-by-one-hour problem, that I've gone and tweaked all the configuration options I can think of, and at this point I'm well and rightly lost. The sad part is that the time is saved correctly in the node, so this indicates to me that event.module is making some kind of "correction" to the time that is totally unnecessary. Perhaps both drupal's core and event.module are making an adjustment?

everybody who has this problem shoudl make sure to run the latest code. there was a problem in an event module version from about May.

I'm 'un-assigning' myself from this bug, and http://drupal.org/node/78572#comment-146693 indicates that this is no longer a problem.

This is all working just peachy for me, but I found that I had to make the change described here:

http://exodusdev.com/event-module-jscalendar-configuration
http://drupal.org/node/65125#comment-106269

in order to get JScalendar and event.module to play well together. In other words, as of today, using event.module + jscalendar together requires using 12h notation in event module config. If you don't, then you will have problems (I think that some of drinkypoo's observed symptoms are caused in part due to this problem.)

Anyway, I think it's safe to say that event.module and jscalendar combo still have some (minor) issues to be resolved, so I thought I'd add a pointer here to help those struggling with using events and jscalendar.

Yet another JSCalendar AM/PM 12/24-hr issue, which seems to be fixed now.