it appears that event.module is incorrectly using gmmktime and gmdate in several places. i can confirm that the timestamps being saved to the event table are not GMT, and i'm pretty sure they are supposed to be. browsing the code, it appears there may be other problems being caused as well, but i haven't been able to confirm this. assigning this to myself, and as soon as i talk w/ crunchywelch to get a better understanding of the coding logic for event i'll work up a patch.

CommentFileSizeAuthor
#5 event_5.module77.79 KBhunmonk
#1 tz_bugs.patch26.79 KBhunmonk

Comments

hunmonk’s picture

hunmonk commented
Status: Active » Needs review
StatusFileSize
new tz_bugs.patch26.79 KB

Attached patch should correct all incorrect usage of timestamp generators, and all event timestamps should be saved to the event table in GMT now. i'd like to ask that anyone interested in a good working version of event.module step up and test this patch out so we can make sure it properly fixes the problem. if you can, please check the actual timestamps in the event table to verify that they are in fact being saved in GMT, not user local time, or server local time. any modules that depend on event's GMT timestamps will not function properly if this isn't working! i've tested it on two machines and all appears fine so far...

i also corrected some other minor time generation issues w/ this patch. ical and rss feed db queries are now done in GMT as they should be, and the event upcoming blocks time until event generation is now correct. for you windows users (and i know you'll cheer for this!), i also fixed that really annoying "Windows does not support times prior to blah blah blah" error.

profpek’s picture

profpek commented

Hi been trying out your patch. not sure how to use "Patch" so did it manualy comparing lines. Seems to work fine except my time zone is GMT - 4 but the times on events are all showing 4 hours ahead, and it displays

Timezone: Etc/GMT+4

running latest drupal with latest event cvs v 1.152

apart from that it seems to running smoothing and big thanks for getting rid of windows infernal whining

Ric

event set as start Aug 25 9 am end 26 3 pm but shows
Start: Aug 26 2005 - 13:00
End: Aug 26 2005 - 19:00
Timezone: Etc/GMT+4

db entries
nid event_start event_end timezone
26 1125075600 1125097200 308

hunmonk’s picture

hunmonk commented

profpek: yikes! that patch had quite a few adjustments, and more than likely you missed one... :) it only takes one missed gmdate() in there somewhere to throw things off. A++ for effort, though. another thing to do is make sure that your timezone settings on your site are all square. is the site timezone set to -4 GMT? if you have user configurable timezones enabled, are they set to the right timezone? check settings/event, too. i've run tests on both win32 and linux, and i'm getting accurate time displays on both. fyi, the timestamps you posted are GMT, so that's looking good. :)

profpek’s picture

profpek commented

I did miss a few or rather added new line but forgot to take out the old. think i have it correct now but still getting the same problem with everything been 4 hours ahead. have everying thing set to gmt -4 , users, system. events are set to use input sitewide and display sitewide.

now if i run event/dst i get Current GMT: 08-25-2005, 14:32 which is again 4 hours ahead off my system and settings. in event db the time zone is set to 308 which in the event_timezones is
308 => array('timezone' => t('Etc/GMT+4'), 'offset' => '-14400', 'offset_dst' => '-14400', 'dst_region' => '0'),
so i guess thats where gmt+ 4 is coming from.

So how do I set the site to the correct zone . In general settings it only lets me set the general time -4 not the location and time new york -4

thanks

Ric

hunmonk’s picture

hunmonk commented
StatusFileSize
new event_5.module77.79 KB

profpek: let's remove all doubt about errors, shall we? attached is the full, already patched, event.module file--and it's working fine for me. try it out and let me know what happens. also, i'd highly recommend checking this out--it will explain diff and patch to you (win32 links at the bottom). it's going to be very difficult for you to accurately test patches w/o this knowledge!

i'm not sure about the timezone naming--i don't have much experience w/ it and didn't write that part. but i can tell you that i'm in USA MST, which i currently think of as DST GMT -6. In event, the display is coming up GMT +6, but my event times are still accurate--so i don't think that issue is causing the time probs.

hunmonk’s picture

hunmonk commented

profpek: hm. looks like the system renamed the file i uploaded. make sure you rename it to event.module before you install it!

profpek’s picture

profpek commented

thehunmonkgroup : thank your for the file and you help.. it is much appreciated.

Still have the 4 hours ahead problem. But strangely only for the start and end displayed as part of a node. the upcoming events block recognises that an event is 10 minutes away and not 4 hr and 10 minutes away. Tried using a different time zone, different settings sitewide/user etc and always 4 hours + . If I revert back to teh old event module v 1.152 then times are displayed correctly

running drupal 2.6.3 but not the latest cvs version.. I'll try installing that and see if it makes a difference

thanks

Ric

hunmonk’s picture

hunmonk commented

profpek: if you go to the 'edit' tab of the node you created, are the local timestamps displayed correctly in event start and end select boxes? looking further into it, i'm seeing that display problem on my linux box now, but not my win32. working on that now...

also, the old event.module did display local times correctly, but only because it did two things wrong and the mistakes zeroed out... ;) the main problem w/ the mod was that GMT timestamps were not being saved to the event table. looking at the results you sent me and my own test results, it appears that we've got that worked out--so now we just need to clean up the conversion back to local time for display purposes

profpek’s picture

profpek commented

thehunmonkgroup: when I go to edit an event they show the local times as I wanted them, but as soon as the node displays, 4 hours is added on.

I tried updating to the latest drupal cvs but the themes are messed up at the moment with it so reverted back to drupal 2.6.3

Ric

hunmonk’s picture

hunmonk commented

profpek: after many hours of investigation, i believe i've traced the problem to a bug in drupal core. you can view the issue and get the patch for that here. don't worry, it's an easy copy and paste... :)

profpek’s picture

profpek commented

True to your word it was a peice of cake. Thank you it all works beautifully now. timezone only shows correctly if I set general setting, Configurable time zones enable and events Event time zone input: allow users to set

Thank you once again.. I will force my self to learn patching

Ric

hunmonk’s picture

hunmonk commented
Status: Needs review » Closed (fixed)

closing this patch. the approach is incorrect. i've spent some more time getting a handle on php's time handling functions, and i'll submit a newer patch that correctly addresses any probs in this module

aaron’s picture

aaron commented
Version: 5.x-2.x-dev » 4.6.x-1.x-dev

I'm getting the same errors ("Windows does not support times prior to blah blah blah") after installing event on a windows server. Should I try this patch, or wait for the newer one in progress?

Thanks for the work you've been doing on it!

- Aaron

Culture Fix Web Identity & Design
Digital Folk Art (my blog)

hunmonk’s picture

hunmonk commented

aaron: there is no newer one. after banging my head off of this issue for awhile, i discovered that the usage of those functions, was, in fact, correct... :/ the php doc doesn't do the world's greatest job of clarifying the time functions, so it was only after many hours of testing that i actually understood how to use them.

the windows error you're getting is actually a problem w/ windows, not this mod. windows machines choke on negative timestamp values with some of the php time functions. i doubt there will ever be a patch committed that will address this, because it would end up being a hack to satisfy windows poor handling of timestamps. my advice to you is:

1. don't run on a windows server, or

2. if you must, get in there and hack the mod to not return negative timestamps to the offending functions