Validate the four predefined front matter date fields when type is string

[snicolai]

with hugo v0.110.0+extended darwin/arm64 BuildDate=unknown from brew

With the following front matter on a page in index.md

---
title: "foo"
date: 2023-02-010T17:46:51-06:00
draft: true
---

Note the extra zero in the day portion of the date.

The page will not be generated and no error message will be issued. I would expect an error message about an unparsable date.

[jmooring]

I agree that it would be helpful if the 4 front matter date fields were validated for JSON and YAML. With these formats, any date that you provide is a string---there is not a native date type.

When using TOML, where dates are a native type, github.com/pelletier/go-toml throws an error when an unquoted value looks like a date but isn't a date.

The native date type provided by TOML is very useful when performing date comparisons involving custom date parameters in front matter.

[MTLChrisLEE]

Hi @snicolai @jmooring ,

I cannot reproduce on my end.

It does generate a page.

On my side, if the date format is wrong, no matter how it's wrong, the date is displayed as "Monday, Jan 1, 0001"

[snicolai-blog]

Perhaps it does generate the page, but sorts it into the wrong location, with 100s of posts and a pagination on the main page, it's likely not to be found.

[MTLChrisLEE]

As I showed in my previous comment, the page gets generated but the date becomes "Monday, Jan 1, 0001".
If the sorting is based on the date, it is highly probable that it's the first item or the last item.
If not, can you at least provide steps to reproduce it?

[mvarie]

It's also possible that the date is interpreted as being in the future, and in that case, no page is generated.

[jcallstrom]

The fix/change that went into 0.135.0 to "validate predefined font matter" dates appears to have broken when using a standard dates:

From .md file
date: September 29, 2024

Error: ERROR invalid front matter: date: September 29, 2024:

[jmooring]

Hugo is doing what it should be doing... it's throwing an error because "September 29, 2024" cannot be cast into a time.Time value. Instead of throwing an error, prior versions silently interpreted your example to be the zero date (0001-01-01 00:00:00 +0000 UTC)... that's what we fixed.

Here are some examples of valid, parsable date strings:
https://gohugo.io/functions/time/astime/#parsable-strings

This issue is closed. Please use the forum (https://discourse.gohugo.io/) if you have additional questions. Thanks.