When your timezone isn't set to UTC, there is a discrepancy between the timezone that you see in the scheduler, and that which is in the selection widget on a session/schedule item, etc.

I'm also guessing that timezones aren't be respected per event, but rather per site. Both need to get fixed, especially since Barcelona and LA aren't in the same timezone ;)

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

timwood’s picture

I think we've run into this on https://www.drupalgovcon.org/. I think it has to do with the Times entity's "Date and time" field uses "Date's time zone" (which I believe PHP's date extension date.timezone config setting) for "Time zone handling", which may be set to UTC. See here: /admin/conference/config/times/manage/fields/field_evttime_date

Should this be set to one of the other available timezone handling options?

timwood’s picture

When testing locally I set the date.timezone to NY and it didn't help with the issue.

timwood’s picture

This patch removes the offset compute for the Time entity label. Not sure if this is the right thing to do or not.

japerry’s picture

Issue tags: +cod 7.x-1.0 radar
japerry’s picture

pcorbett’s picture

I don't think the patch here works quite right in our case. We were experiencing the same issue where the labels on the scheduler were in UTC time and didn't seem to be adjusting for the timezone set for the date field. We're about to schedule sessions for this year's Design 4 Drupal conference in Boston ("America/New_York") timezone. When I inspect the date stored in the database, it shows the datetime as UTC -- I think this is standard for Drupal. So, simply doing away with the offset calculation doesn't make sense.

When I inspect the field_evttime_date object at the start of the getTimeLabel function, it doesn't have an offset stored in it anywhere, which I thought it should given the code that @timwood suggested removing (perhaps because our date field is set to "Site's Timezone"?). Regardless, my fix is to calculate the offset based on the timezone attached to the date object and the date stored in the DB (typically in UTC/GMT). It's possible, after having gone back and forth on this one that everything is messed up, but this is what gets things working for us and hopefully we can come to some kind of conclusion here soon! Open to feedback here, please.

japerry’s picture

So Daniel (CountPacMan) found out that when you set the Date timezone to 'none' -- it sets the date to the actual input time, and sets no timezone at all.

My question is this -- if a time is linked to a particular event, and the event has a timezone on it, why even have a timezone for this field? I think he is right in that we can remove it altogther.

The first usecase I get concerned about here is events in multiple timezones. But this actually fixes that problem. If we have LA (America/Los Angeles) and Barcelona (Europe/Madrid) and the site is default to UTC, thats three different timezones and all with an interesting offset. Users don't have a choice in timezone, so they all get forced into UTC.

The second usecase is an event having scheduled events in multiple timezones. But then I instantly throw that out because even google hasn't figured out how to do that. I don't think thats something we need at all. :-P

The third usecase I can think of is giving the end user the schedule in their own timezone. For online events, this might be useful. But again, we have the timezone from the date field in the event. If we want to build a feature to convert a schedule to a users' particular timezone, lets use the event and its offset, and keep the actual schedule times timezone neutral.

The lastest patch in #2527828: TimeSlot time should not be displayed to account for user's timezone, makes these changes -- I'd be interested if this helps.
https://www.drupal.org/files/issues/2527828-timeslot-time-event-time-fix...

In summary: Conferences (field_dates), and the site itself are the only things that should have timezones. Content with dates that are tagged to an event should just be input with the assumption that the time is the same time as the event.

opdavies’s picture

In summary: Conferences (field_dates), and the site itself are the only things that should have timezones. Content with dates that are tagged to an event should just be input with the assumption that the time is the same time as the event.

+1

pcorbett’s picture

@japerry, I tend to agree, however, the dates are being stored (at least for us, maybe this isn't intended) in UTC time (default for Drupal?). So without a conversion, the scheduler is listing times in UTC, which is wrong. When you edit a given session, Drupal displays the date correctly per the field's timezone settings and I think all I'd expect COD to do is the same when outputting dates. Perhaps we need to look at how Drupal renders dates.

japerry’s picture

ahh, you make a good point -- so in my patch, I simply made the assumption that you put in times relative to your event.

In the case that you don't, this update would be problematic, since the time entity date field wouldn't match the event if its in UTC and your event is in EST. I'll update the script to check to see if the current timezone for a time matches the event, and then adjust the time to match the event timezone if its not correct.

  • japerry committed 925f1ba on 7.x-2.x
    Issue #2407607 by japerry, pcorbett, timwood: Improve timezone handling...
hussainweb’s picture

I came here with a very different (and maybe quicker) way to fix the problem. I am yet to try out the patch here but this essentially worked for me:

I replaced the code in getTimeLabel() method with this:

  public function getTimeLabel($type = 'cod_time') {
    $date_field1 = $this->field_evttime_date[LANGUAGE_NONE][0]['value'];
    $date_field1 = new DateObject($date_field1, $this->field_evttime_date[LANGUAGE_NONE][0]['timezone']);
    $date_field1 = format_date(($date_field1->getTimestamp()), $type);

    $date_field2 = $this->field_evttime_date[LANGUAGE_NONE][0]['value2'];
    $date_field2 = new DateObject($date_field2, $this->field_evttime_date[LANGUAGE_NONE][0]['timezone']);
    $date_field2 = format_date(($date_field2->getTimestamp()), $type);

    return $date_field1 . '-' . $date_field2;
  }

Using date module's functions seemed like a natural way to fix the bug where we attempted to do our own timezone handling. Putting in this code and saving the timeslots worked fine for me. But overall, I tend to agree that it makes sense for timeslots not to do their own timezone handling and depend on the event's timezone.

I haven't tried the dev release as I am weary of upgrading the module and tracking it later (with DrupalCamp Bangalore being this week). I might just apply my temporary fix for now and get this fix when cod has it. I suppose one of the steps to make the update simpler would be to document to temporarily set the site to UTC timezone before updating and then back to intended timezone.

  • japerry committed b5f3ff6 on 7.x-2.x
    Issue #2407607 by japerry: Fix timezone handling on timeslots that aren'...
japerry’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Status: Active » Fixed
Issue tags: -cod 7.x-1.0 radar +cod 7.x-2.0 radar

Knock on wood, this is solved now in the 2.0 branch. I did a bunch of testing with different site timezones and having them different than the event timezone, they all appear to be working.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.