What?

If the block's datetime attribute is set, and it is bound to a Block Bindings source, ensure that the value received is indeed the one set by Block bindings -- i.e. that the fallback value is correctly overridden.

Why?

Quoting WordPress/secure-custom-fields#206 (comment):

Note that if the Date block is inserted and its datetime attribute is bound to a[ Block Bindings source], it will currently show the wrong date on the frontend. The reason is that the datetime attribute is set to the current timestamp upon insertion (the reason for this is to distinguish the block from its deprecated version, which didn't have a datetime attribute, and would instead automatically "bind" to the containing post's publish date).

However, the Date block's datetime attribute isn't listed as bindable yet. While the Date block itself contains logic to provide backwards-compatibility, that code is currently only invoked if the attribute is not set at all.

We'll probably need to amend the latter logic to accommodate for cases where the attribute is set, but to the "wrong" (i.e. fallback) value, and needs to be overridden by Block Bindings.

How?

By fixing the logic, based on an added assertion in the unit test to cover this scenario.

You can verify that the change is indeed needed to make tests pass by reverting it (e328014) and re-running tests.

Testing Instructions

Covered by automated tests.