how to reproduce it:
- enable Driven API, Driven CCK, Driven Node Edition Policy
- configure a date field with time zone (e.g. set to "User's time zone")
- configure Driven NEP to hide date from being edited
- edit a node having such field and the date gets shifted without being edited

something weird is happening when there is no #access to the field, related to date module handling time zones
according to function _date_widget

    // It would seem to make sense to do this conversion when the data
    // is loaded instead of when the form is created, but the loaded
    // field data is cached and we can't cache dates that have been converted
    // to the timezone of an individual user, so we cache the UTC values
    // instead and do our conversion to local dates in the form and
    // in the formatters.

this also happens when using comment_driven (programmatically or not)
but it doesn't show up when trying to provoke analogous behavior with Content Permissions module

Comments

arhak’s picture

arhak commented

I need more feedback on different configurations to compare which ones bring this behavior or not
according to my tests this is only related to dates having time zones
but feedback on date fields has been very poor (to the point that regression bugs got in unnoticed)

nevertheless, I think this isn't a regression bug, since it was first reported by szokes in a private mail dated March 20, i.e. around unstable7
but he didn't opened a public issue despite I encourage him to do so

I encourage users needing to use dates with time zones to get more involved on reporting what they might figure out around this issue

obrienmd’s picture

obrienmd commented

I will attempt to provide more information as soon as possible. In addition to the strange date shifting as mentioned in http://drupal.org/node/741274#comment-2937232, it seems as though when I use comment_driven (newest -dev) on a node with date field, I get the errors:

* There are errors in :
o The dates are invalid.
* The settings have not been saved because of the errors.

Will do more exhaustive investigation soon.

arhak’s picture

arhak commented
Status: Active » Postponed (maintainer needs more info)

reviewing my own notes around this issue I noticed that there are cases I haven't verified due to missing configuration details
- the original report by szokes (referred at #1) was around unstable7 (he didn't report which version neither which configuration) but it wasn't a "shifting" problem, instead he was complaining about non-diff being reported as diff (i.e. equal dates before and after appearing in the diff summary) when having dates with time zone
- this lead me to run my own tests (I don't recall with which version) and then I noticed that for some time zone configurations hours get shifted, but at that time I thought it was a bug in some date's widget (which I haven't confirmed)
- now obrienmd is reporting a "shifting between 0010-01-01 and 2010-01-01" (when using comment_driven programmatically), which is a year's shift I haven't seen so far, it might be due to the same problem of date module handing time zones in their widgets (lazy), but I can't be sure, since configuration isn't detailed

which ever the case might be, I need more details regarding:
- how can the shifting bug be triggered
- and how/which similar configurations don't trigger it
this not only requires knowing how the field was set up, but also the widget and different ways to use it
e.g. Driven NEP, comment_driven's UI, comment_driven_save (programmatically)

in principle, if the bug is reproducible with Driven NEP, it should be a date's bug, because the widget is only getting #access=FALSE and time zone processing doesn't behave properly
nevertheless, we could try to sort it out somehow (since date module is carrying more bugs than they can handle)

arhak’s picture

arhak commented

similar (maybe related) issues:
#491822: Dates getting decremented when saved by one day, on every submit
#605824: Year-field displays as one year early when user's timezone is negative