Problem with timezone handling (caused by date_get_timezone_db returning only UTC)

I created a MR with the patch from #145 (#153 was against a tagged release). I'll try to get familiar with the issue and see where or how I can help.

Running into 💬 DateFieldTestBase::setup() fail setting up user/permission Fixed . Not sure why.

The test failures are probably because of #3194156: Patches and Merge Requests lead to different test results → .

OK, all of the above brought the patch from #145 to a newer version that applies against the latest and also fixed some of the tests errors reported in the 💬 DateFieldTestBase::setup() fail setting up user/permission Fixed issue.

We're in a position now to keep on working on the remaining items.

Rerolled after #3251102 was committed.

I swear I've done this before ;-)

The last submitted patch, 161: date-n998076-161.patch, failed testing. View results →
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

The above fail can be fixed with this: https://git.drupalcode.org/project/date/-/merge_requests/16/diffs#7d300a...

I can work on it further tomorrow.

Are we still aiming to get all the remaining tasks in this issue? I’m happy to help to the best of my ability.

I've already committed the dependencies fix from the other issue. The test failure comes from a new test in DateUpdatesTestCase, one of the pages doesn't load as expected for some reason, though it is still returning a 200 HTTP status.

I think the todo list is reasonable?

Yup, sounds sensible. I’ll try to fix the test and work on some of the tasks.

Might ping you again if I need help or guidance.

@DamienMcKenna - I fixed the test that was failing, rebased the branch with the latest changes from 7.x-2.x, and also addressed, I think, the first two remaining tasks:

* Document what the "date" timezone option actually means.
* Improve the UI around field timezone options, make the implications of each option more clear.

I've done everything via the MR instead of patches. If you want to see a patch version of it just see this: https://git.drupalcode.org/project/date/-/merge_requests/16.diff

You might want to review the wording as I'm fully familiar with the module's inner details so I may have missed something.

I've also got a question about the remaining tasks, namely the drush command and the UI tool for updating data. Isn't this what the update hook does? If that's the case, do we really need the command and the UI tool? Once somebody applies this update, then all the dates should be "correct", right?

Let me know your thoughts.

From slack conversation on March 6th 2023 (summarized):
- Fran: ...I have a question about the test that was created called DateUpdatesTestCase. It assumes that the module is still at the previous version, before applying the update hook, but that is not the case. At the time of loading/running the test, the update 7201 is already applied, so we cannot test the before and after, because there is no before in this case.
- Damien McKenna: Yeah, I realized that would be an issue when I wrote the test, which is why I ignored the schema version and manually executed the update script. That said, the update script (and the test) needs to be removed and replaced with a Drush command and/or admin page to manually process the fields.

Just chiming in that I will need to pull @fjgarlin away for some initiative related work for a little while, so if someone wants to attempt to resolve the items in #174 (or if there is a simpler solution to make it testable) that would be really helpful.

Note that the latest changes are in the MR: https://git.drupalcode.org/project/date/-/merge_requests/16
Attaching a patch matching the current state of the MR too.

Also see #171 as the tests that are run in the MR are a smaller set than the ones run in the patch.

Is this the same issue (in 2.14): when trying to add a node - I get both a node and a php error (using 7.4.33) - the same error, which I have perhaps misakenly posted in the core (field) issue queue. Does this issue belong here instead?:

PDOException: SQLSTATE[22007]: Invalid datetime format: 1366 Incorrect integer value: 'autocreate' for column `uslowestprices_0`.`field_data_field_tags`.`field_tags_tid` at row 1: INSERT INTO {field_data_field_tags} (entity_type, entity_id, revision_id, bundle, delta, language, field_tags_tid) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 77 [:db_insert_placeholder_2] => 77 [:db_insert_placeholder_3] => page [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => autocreate ) in field_sql_storage_field_storage_write() (line 622 of /data/disk/fast1/static/d771/modules/field/modules/field_sql_storage/field_sql_storage.module).

Is it worth considering removing the update hook and drush command altogether into a follow-up? Ie:

1. Without the update dates entered before 7.27 would be no worse off
2. Events created that are that old probably exact time matters little by now
3. Workarounds would then exist because of the new options available

It would make the merge easier right?