Exceptions due ChangedItem, CreatedItem, and TimestampItem implicit dependencies on datetime module

Not sure this is really a novice issue.

#2552799: FieldType with no available widget causes Fatal error added the widget to this field.

#2707057: Remove no_ui from timestamp field type made Timestamp available from the UI.

With the attached, adding this field to an entity and then trying to add the entity via the UI fatals when just loading the page:

Exception: The timestamp must be numeric. in Drupal\Component\Datetime\DateTimePlus::createFromTimestamp() (line 172 of core/lib/Drupal/Component/Datetime/DateTimePlus.php).
Drupal\Core\Datetime\Plugin\Field\FieldWidget\TimestampDatetimeWidget->formElement(Object, 0, Array, Array, Object) (Line: 324)
Drupal\Core\Field\WidgetBase->formSingleElement(Object, 0, Array, Array, Object) (Line: 189)
Drupal\Core\Field\WidgetBase->formMultipleElements(Object, Array, Object) (Line: 104)
Drupal\Core\Field\WidgetBase->form(Object, Array, Object) (Line: 168)
Drupal\Core\Entity\Entity\EntityFormDisplay->buildForm(Object, Array, Object) (Line: 54)
Drupal\Core\Entity\ContentEntityForm->form(Array, Object) (Line: 118)
Drupal\node\NodeForm->form(Array, Object) (Line: 115)
Drupal\Core\Entity\EntityForm->buildForm(Array, Object)
...

The timestamps on nodes, etc, use this widget for base fields. I suspect those are never empty, so they never barf here. I think I see what is happening, but want to wrap my head around this first before posting more work.

I'll see if I can work this into a failing test tonight or tomorrow.

Widget fix and my work-in-progress on the test.

#9, it was a timestamp w/o a default value.

-    $default_value = isset($items[$delta]->value) ? DrupalDateTime::createFromTimestamp($items[$delta]->value) : '';
+    $default_value = isset($items[$delta]->value) && is_numeric($items[$delta]->value) ? DrupalDateTime::createFromTimestamp($items[$delta]->value) : '';

IIRC correctly from debugging this the other night, $items[$delta]->value was coming in as an empty string, which DrupalDateTime::createFromTimestamp() didn't like b/c DateTimePlus::createFromTimestamp() has an explicit is_numeric() check, which led to adding this hunk.

I'll check this again tonight; I was working on a few issues, but I am nearly sure I was doing a clean install between all of them. My dev machine MAMP is also set for PHP7 (so tests run faster...), so I will double check with 5.5 and 5.6, too. It probably doesn't make a difference, but my clean install script defaults to adding a dev-oriented settings.local.php. I may also switch the test to WTB so I can finish it quicker, and then change it to BTB once we know it is good (I'm finding BTB much harder to write from scratch b/c debugging output is less convenient).

I can't make #6 happen any more. No clue why I saw that error other than maybe my database had cruft in it from another issue and I wasn't actually developing from a clean install.

Here is basic coverage of the widget. Probably can be refined. Tried to simplify some of the patterns existing tests use, but may have gone a little too far with assumptions / hardcoded values.

Nits will be picked shortly.

Addressed #14. The "field" @group seems most appropriate; this really isn't datetime proper. Also added an assertion to make sure the "datetime_timestamp" widget is actually used.

Addressed #17 and two other minor things phpcs noticed.

#20, I don't think there are any API implications here, which is why I added a pretty explicit test. I don't think there are any BC problems either. Bottom line is that the timestamp and datetime widgets are formatters aren't compatible because the typed data is different. Timestamps are ints, and datetime are DrupalDateTime (fancy \DateTime). If the datetime widgets or formatters get used with a timestampitem, then you get a fatal (maybe a nasty warning, would have to force a way to reproduce this again). I think we also have pretty decent coverage on created and changed on nodes, which use the timestamp stuff.

Down the road, we could consider whether we want the datetime widgets/formatters could extend the timestamp ones, but haven't put much thought into whether it is worthwhile.

But should the datetime module alter the defaults to use it's formatter when it is installed?

#24, I don't see how datetime.module can do this. The typed data is different. Timestamps, as provided by core, are signed integers. Datetime (and daterange) are ISO strings. We could probably support this, but it is decent change to the widgets/formatters and we are trying to simplify the internals of them right now. There are also field setting differences. We would also have to have an uninstall hook to switch them back if datetime.module gets uninstalled. Also not 100% sure we can warn people about this before uninstall with the way dependencies work.

?

What is the current consensus on empty update hooks / post update hooks? I can add one, but a decent amount are being stripped on commit because we have rebuild already from other ones.

OK, here's an empty post-update hook to force plugin definitions to be re-read.