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.
Comment | File | Size | Author |
---|---|---|---|
#14 | date-2375605-cleanup.diff | 1.78 KB | vijaycs85 |
#11 | 2375605_11.patch | 10.2 KB | cosmicdreams |
#8 | 2375605_tests_only.patch | 10.21 KB | cosmicdreams |
Comments
Comment #1
cosmicdreams CreditAttribution: cosmicdreams commentedHere's a patch
Comment #2
cosmicdreams CreditAttribution: cosmicdreams commentedComment #3
cosmicdreams CreditAttribution: cosmicdreams commentedComment #4
vijaycs85Thanks @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.
Comment #5
SoumyaDas CreditAttribution: SoumyaDas commented@cosmicdreams can you please provide steps to reproduce the issue?
Comment #6
cosmicdreams CreditAttribution: cosmicdreams commentedYes:
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.
Comment #7
SoumyaDas CreditAttribution: SoumyaDas commentedI have reproduced the issue and applied @cosmicdreams patch and it is working fine.
Comment #8
cosmicdreams CreditAttribution: cosmicdreams commentedOK, 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.
Comment #11
cosmicdreams CreditAttribution: cosmicdreams commentedProper patch
Comment #12
cosmicdreams CreditAttribution: cosmicdreams commentedComment #14
vijaycs85great 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