So far, you’ve not given us enough factual and reproducible data for us to try to replicate the issue.
Eg. “31 December” doesn’t tell us anything about the actual value of the date field in the frontmatter of the page. Please show us the frontmatter of the page.
You’re not sharing if you’re using Admin to edit the date field, or using a text editor to edit the page file. What Admin shows and what Admin writes might not be the same.
You haven’t shown that you tried to exactly replicate the script shown by @Karmalakas and the debug results you’re getting.
Here is a more simple script that works fine in Grav v1.7.48 and Grav v1.8.0-beta.4. To rule out the effects of Admin, use a text editor only.
Install a fresh copy of Grav from a downloaded zip file.
Add the dump() command to template /user/themes/quark/templates/default.html.twig
Using a text editor, edit file /user/pages/01.home/default.md and add a collection:
content:
items:
'@self.siblings'
When using Grav 1.7.48, run $ touch user/pages/02.typography/default.md. You could also make a change in the Markdown of the page.
This will set the last modified date to today, excluding it from above dateRange
Run the browser on the Home page and examine Clockwork.
Clockwork should show an empty items array
This to be expected because the fallback date is the last modified date of the file.
If the outcome of above script is not as expected, please provide a detailed script, including frontmatter and Clockwork data, so we can replicate it and reproduce the issue.
I’ve spend time on creating two scripts which both cannot reproduce the issue.
Out of curiosity:
Would you mind sharing the results you’ve been getting when you run the exact same steps?
Would you mind sharing what has made you turn to the time part of the date field as being an issue?
In case running the scripts do not replicate the issue and since you are now focusing on the time part, please close this issue because December 31 itself does not seem to be an issue.