Pages dated 31 December not showing in year date range

I have a filter to display pages/posts in a yearly date range like this:

{% set pages_2024 = page.collection.dateRange('01/01/2024','12/31/2024') %}

This works well except it doesn't display any page/post dated 31 December. If I change the date of the page to 30 December it does display.

I have tried changing the end date to 12/32/2024 but no display either.

Is this a bug?
And can anyone suggest a workaround please?

Thanks

@simfin, 🤔 have you tried .dateRange('01/01/2024','01/01/2025')?

Thanks for the suggestion. Yes I've tried extending the date range (including to '01/01/2025') but the 31 December still doesn't display.

To be clear the page does display on its own URL - just not in a (yearly) date range listing.

And this applies to all pages dated 31 December in any date range.

There seems to be a date range blind spot for that particular date.

Can you test this for years 2020 and 2021-23 for example? It's a bit of a stretch, but thinking about leap year

I have tested it with several year ranges - including 2021-23 - the issue persists.

I've also tested it with last days of other (not December) months - and they all display fine.

It really seems to be a bug.

What theme are you using? According to one of our oldest forum members it works as expected with Quark at least on fresh Grav instalation:

Try the following:

• Fresh install of Blog Site skeleton
• Add to template /user/themes/quark/templates/blog.html.twig the following line:

TWIGCopy

{{ dump(page.collection.dateRange('01/01/2024', '12/31/2024')) }}

• Show site in browser and examine clockwork: 0 items found

MARKDOWNCopy

object

* Array(1) object: Grav\Common\Page\Collection
  * object: Grav\Common\Page\Collection
    * *items: Array(0)
    * ~iteratorUnset: false
    * *pages: Grav\Common\Page\Pages
    * *params: Array(6)

• Update page /user/pages/01/blog/hero-classes/item.md and set date to:

TXTCopy

date: 12/31/2024    # was: date: 14:55 08/11/2017

• Refresh page and examine clockwork: 1 item found

TXTCopy

object
  Array(1) object: Grav\Common\Page\Collection
    object: Grav\Common\Page\Collection
      *items: Array(1)
         /www/grav/site-blog/user/pages/01.blog/hero-classes: Array(1)
     ~iteratorUnset: false
     *pages: Grav\Common\Page\Pages
     *params: Array(6)

The issue persists.

I have tried a fresh install of version 1.7.48 with Quark theme. I added a page collection called default, with default.md header including:

content:
    items: '@self.descendants'
    order:
        by: date
        dir: desc
    limit: 999
    pagination: true
    child_type: default

I added the dump twig line to default.html.twig and created a new page under default and dated it 30 December.

In debug/clockwork 1 item is found.
If I change the date to 31 December 0 items are found.

I then repeated the same with a fresh install of 1.8.0 beta 4 with exactly the same results.

Seems like a bug to me.

Let me know if you'd like any more info.

@simfin,

Let me know if you’d like any more info.

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
  TWIGCopy

  {% block content %}
  {{ dump(page.collection.dateRange('01/01/2024', '12/31/2024')) }}
  {{ page.content|raw }}
  {% endblock %}
  

• Using a text editor, edit file /user/pages/01.home/default.md and add a collection:
  YAMLCopy

  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.
  MARKDOWNCopy

  * Array(1) object: Grav\Common\Page\Collection
  * object: Grav\Common\Page\Collection
    * *items: Array(0)
    * ~iteratorUnset: true
    * *pages: Grav\Common\Page\Pages
    * *params: Array(2)
  

• Using a text editor, edit file /user/pages/02.typography/default.md and set the date field:
  TXTCopy

  date: 12/31/2024
  

• Run the browser on the home page and examine Clockwork.
  Clockwork should show an item array containing page 'typography':
  MARKDOWNCopy

  * Array(1) object: Grav\Common\Page\Collection
  * object: Grav\Common\Page\Collection
    * *items: Array(1)
      * /www/grav/xx/grav17/user/pages/02.typography: Array(1)
    * ~iteratorUnset: true
    * *pages: Grav\Common\Page\Pages
    * *params: Array(2)
  

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 have narrowed this down to what I'm sure is a bug re. date ranges and date frontmatter.

The new post is here:

Last page in a date range is not displayed in a listing if that page's frontmatter date field contains a time.

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.

@pamtbaau glad you're back 😉, @simfin i also tested on Grav v1.8.0-beta.3 and can't reproduce the issue

I'll close this as the discussion is continued here.