[#7427] 0 -Date Time error; Failed to parse time string - started after update to 2.4

We have been wrestling with a problem with a Date Time error. Configuration is Joomla 3.9.1, CB 2.3, PHP 7.1.26 (on our test site where we restored the site for debugging.)
So you understand our issue, we use the CB Login module to register new users. It and CB has been rock solid for about 4 years. After updating to the 2.4, it shows the date time parse error. No other updates or changes were made.
And, except for the Date Time error, all else works flawlessly
We and several other developers have had a look and we see no configuration errors, no server side software issues... and if we again restore the 2.3 version, it again works.
It certainly appears there is something causing an issue between the 2.3 and 2.4 updates. Whatever it is it is trying to load a timezone named "YES", and it is failing reading at position 0 of the timezone string ("Y"). We cannot find any place such a timezone is set. This issue appears on two entirely separate server farms, one our live site and the other, our test server site, for what that is worth.
We cannot find any reason but am hoping you can help us sort this out as it's shut down our ability to add new users.
I doubt it's got anything to do with you but since you know the code very well, perhaps you can help us determine where the problem lies.
I have attached copies of the error and the error message log set to Developer.
Thank you for whatever help you can provide.

It's because you set the "Default Registration Value" for the acceptedterms to "YES", which isn't valid. Removing that resolves the issue. Now that I know what's causing this review adding a fix so this won't happen as this is the 3rd report if this happening.

forge.joomlapolis.com/issues/7427

Hi Kyle,
Thanks for the fast resolution to this one. As I figured, it wasn't the update, it was something we were not doing right but we just could not figure this one out for the life of us. Glad you're adding a feature to prevent boneheads like us from having the problem.
Much appreciated.

It previously wasn't an issue since terms and condition fields only have 1 database column, but they've 2 now. 1 keeps track of the yes/no (1/0) acceptance and 1 keeps track of the datetime they consented. The default was being applied to the consented column causing that DateTime error. Not necessarily anything you did wrong, but just an oversight when I implemented the extra column.