Question about date field - time option and filter idea

[sgirard84]

I have this field:

reservationDate:
        type: date
        label: Date
        required: true

First question, as I don't need time, is there an option to remove the time part ?

Having an option "time: true|false" on the date field would be great.

Also, time part makes filtering complex or not possible. Unless there is a way I haven't found yet?

$pages = $this->app->site()->findPage($slug)->children()
            ->filterBy(
                'reservationSatus',
                fn(string $reservationSatus) => in_array($reservationSatus, ['0', '1', '2'], true)
            )
            ->filterBy(
                'reservationDate',
                $date
            );

Any idea?

Thanks

[sgirard84]

Just figured out for the filtering part

->filterBy(
                'reservationDate',
                fn($reservationDate) => ($reservationDate->format('YYYY-MM-DD') == $date)
            );

[giuscris]

Hi @sgirard84, actually your first attempt should have worked too.

I've just found the logic behind converting date input values to string is broken, as it defaults to the date format stored in the options. The only problem is that it's wrongly trying a php style date format like D-m-y as a user-friendly pattern like YYY-MM-DD resulting in broken output.

I'm going to change this default to be always YYY-MM-DD regardless of system options, since it's both a user-friendly and comparable format. Think about sorting instead of filtering. By now sorting by date is cumbersome, you have to call sort with a function just to compare timestamps. At the same time if you display a date in your templates forgetting to format, having a YYY-MM-DD is at least understandable.

---

I'm also going to add an option to remove time, it will default to 12 AM. Thank you for the suggestion.

[giuscris]

Hi @sgirard84,

have you rebuilt panel/assets/js/app.min.js? On the repository there are only the sources.
For convenience here it is: app.min.js.zip

I think the second issue is just because javascript in your browser understands the date-only string as UTC based, and then converts UTC midnight to your time zone (I guess UTC-5).
I wouldn't mind this detail since with this update we don't show the time part in the calendar anymore, so it won't be confusing. When you set time: false, time info will be always discarded on save, we don't risk to save an incorrect date.

---

I'm sorry for the 2.0.0 release, I don't think I'll have time to complete it before the end of next month.
In the meantime I'll release a new beta or two, so you can test it.

Thanks

[sgirard84]

My bad indeed... The component looks good now with final js file.

However, if I open my 'reservation' page with 2025-03-08, it loads as 07. When I save, it actually saves 07 in md file, and shows 06, and so on.

[giuscris]

Ok, I had to change the timezone on my computer to replicate. It seems to me that date-only strings are evaluated by javascript as if they were at midnight UTC, and then the browser converts the date to the local time, basically changing it to your timezone offset from UTC. I'll find a solution in the weekend.

By now I've noticed that if you force 00:00:00 when validating timeless date from php, they remain stable after you make changes.
So as a temporary fix you can change the string "Y-m-d" to "Y-m-d 00:00:00" at this line /formwork/fields/date.php#L64.
At least the date should remain unchanged after you save.

As I said I'll study a more convincing solution.

Thank you for reporting this annoying problem.

[giuscris]

I've found a solution (already implemented).

Basically there are two "details" to consider:

1. JavaScript considers date-only forms as UTC time, which is converted to local time, potentially changing days, but not date + time forms. As MDN says:

When the time zone offset is absent, date-only forms are interpreted as a UTC time and date-time forms are interpreted as a local time. The interpretation as a UTC time is due to a historical spec error that was not consistent with ISO 8601 but could not be changed due to web compatibility.

2. To interpret dates with PHP, we have a convenience method Formwork\Utils\Date::createDateTime() that ends using DateTime::createFromFormat(). This PHP method behaves differently from strtotime() and DateTime::__construct() which defaults to midnight for date-only forms. Instead DateTime::createFromFormat() defaults to current time, which we don't want, unless you prepend ! to the format. In this case it will default to 1970-01-01 00:00 but there is no problem for the date part since we always give at least the date.

What we do now:

1. Always pass a date + time string to the field value, so that JavaScript doesn't make the assumption it's UTC time. Even better, we pass a normalized datetime string. It will still be displayed with the chosen format from Formwork options, anyways.
2. Prepend an exclamation mark internally to have PHP use 0 as a base timestamp and avoid dependence on current time.

We don't need to have an explicit time in the page yaml frontmatter, we have the flexibility to accept date-only strings by default. In other words what I suggested as a temporary fix in my previous reply is completely unneeded.

[sgirard84]

Thanks again for all your work! I'm looking forward for a new beta to get all recent updates with compiled files and dependencies