Display dates with timezones in the user timezone instead

This should be fixed in the -dev version. There are lots and lots of changes since the rc, I'm almost ready to roll a new rc.

If you see problems in the -dev version, please reopen.

Oops, maybe not. I think I mis-read your post. I'll take another look, but the suggestion to move to the -dev version still holds :)

OK, now this is actually fixed. What happened here is partly some bad logic as you pointed out above in thinking that only dates that have timezones might want to display the timezones. The rest of the problem came from my rework to the date theme to make it 'prettier' by changing something like:

Thursday, May 1, 2008 4:00am - Thursday, May 1, 2008 6:00pm

to:

Thursday, May 1, 2008 4:00am - 6:00pm

I had to pull the timezone names out of that logic and tack them back on at the end, but needed to do it in a different way to allow for the various ways that timezones could be formatted.

Anyway, committed to both 5.2 and 6.2.

Thanks!

The doubled timezone name was a small bug (I needed to trim the timezone name before replacing it out of the dates).

The other issue sounds like you want the Date module to do something I never intended it to do -- set a timezone on a date and then not display it and instead display the user's timezone. I have made the assumption that if you give dates their own timezones it's because the timezones are an important piece of information about the event. I usually use that to display events that should always be displayed in their own timezone because they're real-world events that will happen at that date and in that timezone. If you're attending a real-world event, you don't need to know what time it will happen in your timezone, you need to know what time it will happen in its own timezone.

Online events or things without timezones are the ones you might want to translate into the user's timezone -- things like the date a node got updated or the date and time of an online event -- and I never give them their own timezone since they don't really have one and it always makes sense to show them in the user or site timezone.

Trying to do something else would be a feature request and we'd need to think about how to offer that option without confusing everyone. It would need to be configurable, since that is not the way everyone would do it.

I missed item 3, I'll double-check that. What PHP version are you using?

As to the theory of how timezones should be displayed, see http://wiki.mozilla.org/Calendar:Timezones, http://groups.google.com/group/google-calendar-help-publishers/msg/44253..., http://tools.ietf.org/html/rfc2445#section-4.3.5 (there are lots of other similar links) for discussions about the differences between events that have a fixed timezone where the timezone is an important component of the date and 'floating' timezones that are intended to be displayed in the user timezone.

OK, I can see the use case. For now, you can override theme_date_display_combination() to get this working. you have the raw date info available to you there and you can convert the raw date to the user timezone and display it.

Subscribing

While searching for existing issues in the date queue that could explain what I'm running into over at #336255-11: CCK datestamp fields totally broken and fields without timezone handling mostly broken, I found this. This doesn't seem relevant to the bug I'm currently hunting (which I just submitted as #336829: nodes with CCK datestamp field using "Site's timezone" handling appear to be saved with user's TZ instead for the interested reader). However, I wanted to chime in here that IMHO, Crell is right on, and there are definitely plenty of use-cases for this sort of functionality. Try scheduling d.o downtime, IRC meetings, etc. They happen at a specific, absolute moment in time. People viewing that event don't care that the d.o server lives in US/Pacific time and that's the "local" timezone for the downtime. All they want to know is when d.o will be offline relative to their own timezone.

No new features in D5, moving feature requests to D6.

Subscribing.

Bumping this feature request for D6 (at least).

We maintain a calendar of meetings for our international NGO. These meetings are typically attended both in person and online from a variety of locations around the world and the timezone of the meetings' date/time is typically set to that of the physical location of the meetings. Often, these meetings are scheduled by users who are travelling and not currently in the timezone that the meeting will take place in.

We need to allow the user creating the meeting node to be able to attach a timezone other than their own to the meeting date/time and for that meeting to be displayed on a calendar adjusted for the viewing user's timezone so they don't see a 1:00 p.m. meeting in Seattle displayed alongside a 1:00 p.m. meeting in Cairo and have to constantly calculate the various meeting timeshifts on their own.

I'll look into overriding theme_date_display_combination() but having this as an option 'out of the box' would be a substantial benefit/improvement.

It appears that all that is needed is to allow the timezone field to be exposed and editable when the Time zone handling is set to "User's time zone". This can be accomplished by changing one line of code - the test in the if statement in the _date_widget() function in date_elements.inc:

Change this:

if ($field['tz_handling'] == 'date') {
  $element['timezone'] = array(
    '#type' => 'date_timezone',
    '#delta' => $delta,
    '#default_value' => $timezone,
    '#weight' => $field['widget']['weight'] + .2,
    );  
}

to this:

if ($field['tz_handling'] == 'date' || $field['tz_handling'] == 'user') {
  $element['timezone'] = array(
    '#type' => 'date_timezone',
    '#delta' => $delta,
    '#default_value' => $timezone,
    '#weight' => $field['widget']['weight'] + .2,
    );  
}

This doesn't appear to create any problems as far as I can tell and allows timezones other than the author's timezone to be set in the node while retaining the behavior of "User's time zone" handling.

I'm attaching a patch with this comment.

One caveat to the patch is that when you save a node with a date/time using a timezone other than your own then reopen the node for editing, the date/time and timezone will be converted using your timezone (because you've set the site to use "User's time zone" for Time zone handling) and will display values adjusted for your timezone rather than the values you originally entered. This may be unexpected and/or disconcerting but is a correct behavior based on the configuration settings.