Dates in custom fields not always stored in the correct format

[mattcarras]

Debug mode

• I have enabled debug mode
• I have read checked the Common Issues page

Describe the bug

We've found assets imported into your hosted solution using the custom fields in the DATE format would get seemingly scrambled every time we went to edit them. Doing a bit of digging I believe this is a problem with either the formats given to the datepicker or how custom fields are being validated and stored. I see where you cast into date/datetime and use strtotime with the 'Y-m-d' format for built-in fields, but I don't see where snipe-it either casts and re-converts, or specifies date_format, when storing custom fields. Because the validation doesn't seem to specify Y-m-d format, bad data can easily be entered into the database using the date format specified in the sample CSVs.

It's also a bit confusing that the datepicker doesn't show the specified localized date format when editing. The code appears to always set the format explicitly to "yyyy-mm-dd".

This can be reproduced in the demo by going to the purchase field, entering the date as mm/dd/yyyy (which is accepted), and then clicking on it again to edit it.

Reproduction steps

1. Create a custom field using the DATE format.
2. Either import assets or use the REST API to create/set assets using the custom fields in a format other than Y-m-d.
3. In the web GUI, select to edit the asset.
4. Select to edit one of the custom DATE fields.
5. Notice the date is re-interpreted as Y-m-d, scrambling it.
   ...

Expected behavior

Either the datepicker needs to be able to handle formats other than Y-m-d, or custom date fields need to always be stored in that format.

Screenshots

No response

Snipe-IT Version

6.0.9

Operating System

Linux

Web Server

Whatever version the official hosted solution uses

PHP Version

Whatever version the official hosted solution uses

Operating System

No response

Browser

No response

Version

No response

Device

No response

Operating System

No response

Browser

No response

Version

No response

Error messages

No response

Additional context

No response

[inietov]

I think that is an edge case to manually enter a date into the input form... I add a PR to make the date format fields as read only so the datepicker element is forced to input dates. I'm open to consider other options to mitigate this. So if anyone doesn't feel comfy with this fix, let's chat!!