Support javascript dates in pubDate alongside RFC 822 formats

[goblinfactory]

For discussion (I don't have a strong opinion on this)

Support javascript dates in pubDate alongside RFC 822 formats

The rationale for this is to make the creation of markdown files as well as the editing of front matter be an activity more accessible and friendly for non developers. So that a new blog post front matter could be

---
date: 16 Jan 2024
title: Anyone have any suggestions for a budget (yet powerful) home server? 
hero: budget-home-server.png
---

Instead of

---
date: 2024-01-16
title: Anyone have any suggestions for a budget (yet powerful) home server? 
hero: budget-home-server.png
---

This would alleviate the need to use a pretty date control when referring to the pubDate in layouts.
This only requires the following change (plus a few small other changes for some other edge cases, but it's not a lot.

    constructor({ posts }) {
      this.items = posts.sort((a, b) => {
        const dateA = new Date(a.date.replace(/\./g, '/'));
        const dateB = new Date(b.date.replace(/\./g, '/'));
        return dateB.getTime() - dateA.getTime();
      })

I actually added this to my own layout.html because I wanted to keep the dates in the more human readible format since my semi-dyslexia means I can't easily see the difference between a group of numbers, but having the month as a word helps me hugely tell the difference when scanning text.

I'm ok if I have to stick to RFC 822, but it got me thinking how many other people / users are similar to me?

Perhaps we can simply expose a post.prettyDate or post.Date property that keeps either value.
We can detect whether a user has specified either value, and set the other accordingly.
e.g.

---
date: 20 Jan 2020
---

would automatically set pubDate to 2020-01-20 and also date to 20 Jan 2020? And vice versa.

I think as we expand collections, this type of smart meta data would avoid users writing custom pretty formattings for different display uses?

NB! : The pretty date is actually javascript compatible. new date('1 Jan 2024`) is valid.

[tipiirai]

Thanks to the internal YAML parser, the following formats are "natively" supported:

pubDate: February 5, 2023 12:00 PM
pubDate: February 5, 2023
pubDate: Feb 5, 2023

Just tried with the simple blog template and the date was updated live via hot-reloading.

[tipiirai]

Here is the official YAML specification regarding the feature

[goblinfactory]

Nice! I'll update the collection test, to make it explicit, so that the test can serve as documentation.

[goblinfactory]

@tipiirai
hmm, I'm still looking into this, but at first look it seems that only the 2020-01-03 format get's turned into an actual date. The rest are picked up as strings. Ignore the comment with the wrong expected sort order.
Correct expected sort order is #First, Second, Third, Fourth <-- Adding a comment explaining why the order is expected such is helpful. i.e. where does null get sorted, and do parent folder status affect sort order etc.

It's easy to get false negative or positives from tests, since the string values can give unexpected results.
Let me dig into this a bit more. Ignore the actual order for now, I'll fix that in the test later, the reason for my comment here is ONLY about the fact that only the one format actually becomes a date value, the rest are picked up as strings. (the purple value in the console log output)