[datetime-field_type] Upon submit, getting error saying invalid format

Created 6 years ago by emergingdzns

I've got a date time field configured thusly:

[
    "default_value" => null,
    "mode"          => "date",
    "date_format"   => "m/d/Y",
    "year_range"    => "-50:+50",
    "picker" => false
]

I'm using the Pyro built in module stream form builder functionality. I've defined the fields by name only (no special config) and the date field is in the list. The input mask is showing up and working just fine without the date picker there. The user can use the up/dn arrows to change days, months and years or simply type the date out. However, when the form is submitted (the handler only does a save() it doesn't do any extra validation or anything) it returns with an error that the date is invalid. It didn't do this when the picker was set to true.

piterden — 6 years ago

Remove picker false

Link

emergingdzns — 6 years ago

I can't. My client doesn't want the date picker. They don't like it. The dates being entered are sometimes years old and the method of changing years is too confusing for their simple minded users (lots of older folks).

Link

ryanthompson — 6 years ago

You might try rolling back to 2.2

The 3.0 branch was a big push away from the 2.2 text input since we found a native JS picker. I've been fussing about with the 3.0 input mode for a while and will need to revisit. 2.2 / 3.0 are interchangeable. Just one focuses more on text UI vs picker.

Link

emergingdzns — 6 years ago

Ok I rolled back to 2.2 and now it's jacked up. The field now defaults (even though config is set to date_format => 'm/d/Y' and mode => 'date') to this: December 6, 2017 18:00

Can I actually change the TYPE of field with a migration? I know I can change the config of the same field type. I may have to bite the bullet and change this to a text with input mask and just do all the conversion work in the form handler or something.

Link

ryanthompson — 6 years ago

You can change the type with a migration yes.

However double check that your format is in the selectable config options for the input mode. It's less versatile than the picker.

Link

emergingdzns — 6 years ago

It is in the right format based on the code for 2.2. Unless I'm missing something: https://github.com/anomalylabs/datetime-field_type/blob/67660e2d84bb2ab977c0e40d4b7125c665d7a52b/resources/config/formats.php#L14

Looking at the 3.0 code, it looks like maybe the carbon system has a time with the createFromFormat on this line: https://github.com/anomalylabs/datetime-field_type/blob/a8e8fd531068d1ed58876039eb00f7ac43c1d506/src/Validation/ValidateDatetime.php#L31 the config format is set to 'm/d/Y' and the value is something like '10/06/2012' which is a valid date. Maybe there's a problem with Carbon?

Link