Problem/Motivation
The log messages generated by the webform_scheduled_email sub-module sometimes include a date-time string. For example:
"Foo: Submission #1: Email scheduled by 'Reminder email 1' handler to be sent on 2024-07-24 16:15:00."
That is enough information if you, your site, and your site's users all happen to share the same timezone. On my site I have users across many timezones, any of which could be scheduling webform emails, so this is not enough information for me to determine when a particular email was actually scheduled to be sent. Is that "2024-07-24 16:15:00" expressed in the site's default timezone? Or perhaps the scheduling user's timezone? If the scheduling user's TZ, what was the scheduling user's timezone set to when this log message was generated? Hopefully that's remained consistent but I cannot say for sure...
Without timezone information on this date-time string it becomes really hard to say when exactly that email was scheduled to be sent. If still queued I could probably find out by looking for the corresponding record's unix timestamp in the webform_scheduled_email database table, but that is a lot of extra work when the log message could have simply spit out, perhaps, a more complete ISO-8601 with that valuable timezone information at the end.
Steps to reproduce
1. Enable webform_scheduled_email and turn on the date + time scheduling granularity option in webform.
2. Enable webform logging.
3. Schedule an email in a webform_scheduled_email handler and see that the resulting log message lacks crucial timezone information in the date-time string found within the log message.
Proposed resolution
Update the webform_scheduled_email's date-time string format from 'Y-m-d H:i:s' to ISO 8601 ('c') (or something with timezone information like 'Y-m-d H:i:s T' or 'Y-m-d H:i:s e') so webform_scheduled_email begins outputting date-time strings with that crucial timezone information at the end.
In local tests of the switch to ISO 8601 ('c') this small change does not appear to change or otherwise have any impact on what is stored in the database, but does produce much more usable log messages for those of us on multi-timezone sites. Internally, strtotime() consumes these date-time strings the same, because the timezone information webform_scheduled_email appends is the same as would be assumed by strtotime() in the absence of it.
Remaining tasks
Agree on proposed resolution / timezone-inclusive date-time format, patch, & review.
User interface changes
A webform_scheduled_email log message generated by an activity of a user in the Pacific timezone would look like one of these (depending on date-time string format with TZ info choice):
"Foo: Submission #1: Email scheduled by 'Reminder email 1' handler to be sent on 2024-07-24T16:15:00-07:00."
"Foo: Submission #1: Email scheduled by 'Reminder email 1' handler to be sent on 2024-07-24 16:15:00 PDT."
"Foo: Submission #1: Email scheduled by 'Reminder email 1' handler to be sent on 2024-07-24 16:15:00 America/Los_Angeles."
Instead of:
"Foo: Submission #1: Email scheduled by 'Reminder email 1' handler to be sent on 2024-07-24 16:15:00."
Even if I don't happen to be in the Pacific timezone myself, with that crucial timezone information at the end I can now tell exactly when the email was scheduled to be sent. No more ambiguity.
API changes
1. WebformScheduledEmailManager::getDateFormat() and likely WebformScheduledEmailManager::getDateFormatLabel() would begin returning a format that includes timezone info if the date type is 'datetime'.
2. Docblocks on WebformScheduledEmailManagerInterface::getDateFormat() and WebformScheduledEmailManagerInterface::getDateFormatLabel() would change to either not state the formats they assume their implementing classes will return, or need to be updated to reflect the new, assumed 'datetime' date format.
Data model changes
None.