Native DatePicker: min and max HTML attribute shouldn't contain time

[buddhaCode]

Description

Setting the minDate()/maxDate() restrictions on a native Date input doesn't restrict the selection in the GUI. Currently, the min/max attribute on the HTML tag contains the time, even when one is just using the DatePicker (not DateTimePicker). According to the HTML docs, a date input should only have the date and ommit the time.

DatePicker::make('Native Date Picker')
  ->minDate(now()->subDays(3))
  ->maxDate(now()->addDays(3))

Produces:

<input [...] max="2024-03-26 18:14:56" min="2024-03-20 18:14:56" type="date" [...]>

But should produce:

<input [...] max="2024-03-26" min="2024-03-20" type="date" [...]>

The native date time input works fine. But according to HTML standard, the space between the date and time should be an T. But Chrome also accepts the space. And the GUI only restricts the date selection, not the time selection. But I guess thats regular chrome behavior.

The JS date and date time picker work fine as expected.

Visual changes

Before (tested with Chrome 123 on Mac/Safari 17.2.1 on Mac/Firefox 124 on Mac):

After:

Functional changes

• Code style has been fixed by running the composer cs command.
• Changes have been tested to not break existing functionality.
• Documentation is up-to-date.

[buddhaCode]

Hey Dan, thanks for reviewing my PRs. What can I do, that you don't have to rewrite my PRs completely? ;)

[danharrin]

There's not some general tip I can write that will improve them. I do this to most PRs. There's just some insights that most people don't have that are a little specific to people who have built so much of the framework. In this case, I didn't like the original implementation since I thought it was fragile - if the type of the max date / min date variable changed in the future away from a string then substr wouldn't really work, and if the date format changed to include extra characters then it also would break as the substr indexes would be out. I just changed it to make it so that it hopefully wouldn't break in these cases, to ease maintenance in the future.

With the other PR, there were other places that also needed the implementation. I also copied the implementation from the text column/entry instead of introducing Collection::wrap() for consistency. I didn't like that a object collection was being created in all cases even though we didn't use any of the collection methods, it felt like an inefficiency.