We can now display event dates on a calendar using views. May need to restructure the event calendar api to remove assumption that date is a unix timestamp and/or recast the cck date as a unix timestamp before passing it to the calendar.

Comments

karens’s picture

karens commented
Status: Active » Needs review

Latest cvs version has support for adding any date field to a calendar view. Select the field labeled 'Calendar: Start Date' or 'Calendar:End Date' to use it. These dates can also be used as filters and arguments.

RayZ’s picture

RayZ commented

Are you sure things are tagged as intended in cvs? From the commit history (http://drupal.org/project/cvs/67060) and from a comparison of cvs checkouts with and without -r DRUPAL-4.7, it appears to me that these latest changes were made in the 4.7 branch, as opposed to the main branch. I'd like to start testing this soon, and just wanted to make sure I'm getting the latest code.

karens’s picture

karens commented

You may be right. I was having trouble getting things into the right branches. I'll take a look and try to get it straightened out.

karens’s picture

karens commented

I did have files mixed up. I decided the changes will work OK in 4.7 version, so I updated cvs to match, and made a few other fixes to both versions.

RayZ’s picture

RayZ commented

Thanks. I'm testing it out and have run across a problem that I think is related to a timezone issue. I'm using the latest cvs checkouts of everything using DRUPAL-4-7 branch of drupal core and event, and the HEAD version of cck, date and views.

I'm using a cck date field that is set to use the site timezone (US/Eastern) and I have 5 events in March and 4 in April. However, my view lists
March (4)
April (5)
but then the calendar for each month only shows 4 events. There is an event at 7:00pm on March 31st that is somehow getting counted as an April event, but isn't showing up on either calendar. Same behavior if the date field is a datestamp or an ISO date field. If I use the event module start date instead it gets it right.

Thanks for all your work on this. I'm really looking forward to using this event_views feature.

karens’s picture

karens commented

I have been looking into this and it is because there is a difference between the way the date.module handles timezones and the way event handles timeszones. Even though your event dates look right and cck dates look wrong, I *think* date.module is storing the right value in the db and that here is a problem with the way that event is handling them, but I need to confirm that because it is entirely possible that it is the date module that is wrong. (I am seeing problems in the event module if I try to use an event-specific timezone that is different than the site timezone or the server timezone, for instance). I am adjusting both types of dates the same way in event_views, the way that works with the event module, which is why they are behaving differently in event_views. Once I confirm the date handling in the date module I then need to adapt the timezone adjustment in event_views accordingly.

It looks like this will only affect dates that are on the cusp of a month, so hopefully you can live with it until I figure out the correct fix to make.

karens’s picture

karens commented

Also, just to help me get this working right, what timezone handling did you use for your cck date and what timezone should that handling be creating? And what is your site timezone and your server timezone?

karens’s picture

karens commented

Oops -- I see you already told me about your timezone handling, except for the server timezone. Is the server set to Eastern, too??

merlinofchaos’s picture

merlinofchaos commented

KarenS: If you're using from_unixtime() on this, MySQL applies the MySQL server timezone and doesn't let you adjust it; ordinarily, at least with unix timestamps, Drupal puts these in GMT, so there can be a disparity of the server is not operating in GMT.

If you're running into this problem (I don't know for sure; it doesn't look like you should be using it for these sorts of dates) you might try calling _views_get_timezome() which will, if you've go the right mysql version #, send a command to set the session timezome appropriately to eliminate this.

karens’s picture

karens commented

Thanks for reminding me that mysql date functions do a timezone adjustment, too. I had forgotten about that one. I'm trying to get the right values after taking into account the way that php date, mktime, gmdate, gmmktime and strtotime all automatically try to adjust for the server timezone in various ways, depending on the php version, since that creates problems if you're trying to use a timezone that's different from the server timezone. Timezone issues are a real pandora's box...

RayZ’s picture

RayZ commented

Karen, by "server timezone" I assume you are referring to the "default time zone" setting in "admin/settings"? I currently have that set to -0400 (Eastern Daylight Time). Btw, should I be manually changing this back and forth between -0400 and -0500 as I go off and on DST, or is that going to mess things up? Seems clear we need a timezone as opposed to just an offset for the server timezone as well.

I confess this Pandora's box really has me a bit confused about the best way to set things up. Given that all my dates/times are w.r.t the server's local timezone, I'm tempted to set my offset to 0000 and tell all my date fields to just use GMT and not do any adjustments. But I'd prefer to do it right, if we can get things working consistently. Thanks again.

karens’s picture

karens commented

By 'server timezone' I am referring to the timezone setting of the server itself. If you host your own server, it is probably whatever you set your site timezone up for. If you are on a hosted server, it's probably the timezone where the server is physically located, which could be something different than what you set up as your site default. Drupal doesn't control the server timezone, and there is no drupal setting for it, it's controlled by whoever operates your server. The drupal admin/settings controls your 'site timezone', which is your preference for the display of date info in drupal.

The pandora's box happens because we have, potentially, several different timezones to account for - the server's timezone, the site's timezone, the user's timezone, and an event- or date-specific timezone. On top of that mysql has its own idea of what the timezone is (should be the same as the server, but could be different if mysql is hosted on a different machine than the site is). And on top of that is the problem that many database date functions and php date functions automatically do some adjustment to a default timezone that could screw up my timezone adjustment, and the exact thing they do varies depending on the version of php or mysql you are using.

Anyway, the goal is for you to be able to do exactly what you are describing - create a date during EDT for an event that will happen in EST, or in some other timezone, and have the value stored and displayed correctly without worrying about changing your site settings (by using the site timezone name you provide when you create the field). I just need to be sure that the date.module is going to do that reliably in all situations, and that may take a bit of tweaking.

Partly because of this, I added in the option to do no timezone adjustments - which will accept whatever you type in and display it the same way. Or, as you said, you can just use GMT for everything.

RayZ’s picture

RayZ commented

Ah, server timezone is what is set in the OS? Yes, that's US Eastern Daylight Time.

I think there may be an issue with the date.module itself (http://drupal.org/node/72052)

Also, I'm not sure how the views selects the rows for a particular month, but clearly in order to do it correctly it needs to select based on the date AFTER timezone correction. I.e. In the example below, this entry should appear under March, not April, even though the database says 2006-04-01T00:00:00.

database                display                 apparent TZ adjustment
2006-04-01T00:00:00     Mar 31 2006 07:00 pm    -5 hrs
RayZ’s picture

RayZ commented

FYI, with the latest updates to the date module and timezone fixes I still have the issue described in #5 above.

Should we close this issue now that this feature has been commited and create a new issue for this bug?

karens’s picture

karens commented
Status: Needs review » Fixed

Actually I confess I forgot about that issue in this long thread. Yes, let's close this issue and start a new one specific to that issue.

RayZ’s picture

RayZ commented

Opened a new issue at http://drupal.org/node/72715

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)