My current problem with setting a site to use the Date's timezone strategy is that the UI lies to the user. It says that you can set a timezone for each date within a multi-value date field. But when a user does that, the timezone they save is always converted back to the first date's timezone.

This is because of line 90 of date_elements.inc which reads:

$timezone = date_get_timezone($field['settings']['tz_handling'], isset($items[0]['timezone']) ? $items[0]['timezone'] : date_default_timezone());

See? It's always going to use $items[0] timezone, even if there are multiple items with different time zones. But those additional items have the ability to set their own timezone.

Additionally:
It's not the save function that has a problem, dates happily store their different time zones properly.
It's not the load function that has a problem, dates happily load from the db with their different time zones properly.

It's this widget form that hard wires the timezone that is stored on the first value to every other value.

Why?

To me this seems like a small and trouble-free change that fixes my current issue.

$timezone = date_get_timezone($field['settings']['tz_handling'], isset($items[$delta]['timezone']) ? $items[$delta]['timezone'] : date_default_timezone());

But maybe there is some context to why this is the way it is that I don't understand. Please help me understand.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

cosmicdreams’s picture

FileSize
762 bytes

Here's a patch

cosmicdreams’s picture

Issue summary: View changes
cosmicdreams’s picture

Status: Active » Needs review
vijaycs85’s picture

Issue tags: +Needs tests

Thanks @cosmicdreams for taking your time to report & issue patch. As we discussed on IRC, it is good to have some test cases to cover this scenario.

SoumyaDas’s picture

@cosmicdreams can you please provide steps to reproduce the issue?

cosmicdreams’s picture

Yes:

1. Create a date field with unlimited cardinality and select the Date's Timezone date storage strategy.
2. Create a node that uses the date field to hold muliple values of the dates. Be sure to select a different timezone for each value you add to the date field.
3. View the node and notice that once saved, the node will display the dates with their different timezones.
4. Edit the node and notice that the edit form displays each date as having the same timezone. Specifically, any timezone you added to the second, third, etc. dates has been replaced by the timezone value you assigned to your first date.
5. Save the node again and view it. Notice that the act of editing the node and saving it replaces the intended timezone of date value

In summary, if we allow users to set different timezones for dates in a multi-value date field, we should ensure that the system proper persists that data and not destroy it when a user edits the node.

SoumyaDas’s picture

I have reproduced the issue and applied @cosmicdreams patch and it is working fine.

cosmicdreams’s picture

FileSize
10.21 KB
10.95 KB

OK, I was finally able to write some new tests that show the error and a patch that includes the tests that shows it fixed.

Hopefully we get the red and green that vijaycs85 has requested.

The last submitted patch, 8: 2375605_tests_only.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 8: 2375605_8.patch, failed testing.

cosmicdreams’s picture

FileSize
10.2 KB

Proper patch

cosmicdreams’s picture

Status: Needs work » Needs review

vijaycs85’s picture

Status: Needs review » Fixed
FileSize
1.78 KB

great work @cosmicdreams and thanks @ssdas for the manual testing and confirmation. Just made few code cleanup(attached diff file for your reference) and committed it to 7.x-2.x

Status: Fixed » Closed (fixed)

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