Eleventy Does not Accept Valid YAML Datetimes in Front Matter

[faokryn]

Operating system

Fedora Linux 38

Eleventy

2.0.1

Describe the bug

Eleventy does not accept all valid YAML datetimes in the date key of template front matters.

Per the Eleventy Content Dates documentation, Eleventy should allow any valid YAML date as a value for the "date" front matter key. Per the linked YAML timestamp documentation, whitespace separation of the date, time, and timezone sections of the timestamp are valid for YAML (note specifically the "Regex" and "Example 1" sections).

However, this is not reflected in Eleventy's behavior; datetimes which are valid for YAML but not for ISO 8601 cause an error, e.g.:

• date: "2024-01-01T00:00:00" # valid ISO 8601, valid in front matter
• date: "2024-01-01T00:00:00-05" # valid ISO 8601, valid in front matter
• date: "2024-01-01 00:00:00" # valid YAML datetime, invalid in front matter
• date: "2024-01-01 00:00:00 -5" # valid YAML datetime, invalid in front matter
• date: "2024-01-01 00:00:00 -05" # valid YAML datetime, invalid in front matter

Reproduction steps

In your template's front matter, use a valid YAML datetime that is not a valid (strict) ISO 8601 datetime due to whitespace, e.g.:

• date: "2024-01-01 00:00:00"
• date: "2024-01-01 00:00:00 -5"
• date: "2024-01-01 00:00:00 -05"

Expected behavior

Any valid YAML datetime should be valid for the Eleventy "date" front matter key, or the Eleventy documentation should be updated to reflect the actual behavior.

Reproduction URL

No response

Screenshots

N/A

[faokryn]

Additional Context

#1669 is related: it mentions similar flexible date parsing, but in the context of a feature request, not noting that the requested behavior is actually already within the documented (if not actual) behavior.

As noted in the comments of the issue above, Eleventy uses Luxon under the hood to parse the "date" front matter key. This may represent a change in Luxon's behavior in favor of stricter ISO parsing between the writing of the relevant Eleventy documentation and now, but I did not go so far as to check the histories of Luxon and the docs.

[zachleat]

YAML dates are unquoted, no? We only use Luxon when the date property is a string.

[zachleat]

Related #867

[zachleat]

This is an automated message to let you know that a helpful response was posted to your issue and for the health of the repository issue tracker the issue will be closed. This is to help alleviate issues hanging open waiting for a response from the original poster.

If the response works to solve your problem—great! But if you’re still having problems, do not let the issue’s closing deter you if you have additional questions! Post another comment and we will reopen the issue. Thanks!