Schema changes.

Problem/Motivation

There is a project on the go (since 2015.. ughh) to allow core date/daterange fields to support timezones. At first glance this would appear to not affect this module as the scheduling date field does not use time.

That being said, trying to work the patch from here: #3185750: Composer friendly patches adding timezones to core date fields and a few issues arise from it related to this module. Which yes, could/should be handled by their db update - but also wouldnt need to if this module used a more common storage schema approach.

The db update script attempts to modify ALL date and daterange fields in the db to include a new timezone property (column in the field table). Whether these are meant to collect time or not, is not taken in to account as this is not a different db structure and its possible if this was a new field (with no content); someone could modify the field later to add time collection (doesnt apply for your module).

There are two issues that come up as a result of this module when trying to run that db update:

1. the scheduled date field is oddly defined in the db as scheduled_date_ (then with _value and _end_value attached as usual). The extra _ at the end of the field name is not Drupal std and causes the db update to fail.

2. the sitewide_alert_field_revision table should be a clone of the sitewide_alert_field_data table; but it is missing the scheduled date fields.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes