Some valid yaml dates are treated as invalid

[jyn514]

Bug Report

Environment

Zola version: zola 0.16.1

Expected Behavior

This front-matter should parse successfully (see https://www.yamllint.com/ for an example of another tool that can parse it; this was originally migrated from a Jekyll site which can also parse it):

---
layout:	post
title:	"Hosting an SSH Server"
date:	"2017-12-27 20:46:24 -0500"
excerpt: I decided one day that I really wanted a remote server.
audience: tech-savvy
---

Current Behavior

PS C:\Users\jyn\src\third-website> zola serve                     
Building site...
Error: Failed to serve the site
Error: Error when parsing front matter of section `\\?\C:\Users\jyn\src\third-website\content\blog\2017-12-27-Hosting-an-SSH-Server.md`
Error: Reason: YAML deserialize error: Error("failed to parse datetime", line: 2, column: 1)

I think the problem is that dates are unconditionally parsed as toml dates, which is not correct:

zola/components/content/src/front_matter/page.rs

Lines 31 to 33 in 39bfbcd

	/// Date if we want to order pages (ie blog post)
	#[serde(default, deserialize_with = "from_toml_datetime")]
	pub date: Option<String>,

Step to reproduce

Add the given frontmatter to any .md file in content/blogs.

[Keats]

Thanks for the clear bug report.
Anyone wants to grab that?

[Kidsan]

@jyn514 Unless I'm mistaken this is an error with your date value and not to do with parsing the field. The supported date formats are YYYY-MM-DD and RFC3339. The field should also not be quoted. See the comment on the date field in the docs: https://www.getzola.org/documentation/content/page/#front-matter I have no experience with Jekyll but it looks like it does not use the same date formats in front matter: https://jekyllrb.com/docs/front-matter/

Incidentally, the page you linked isn't parsing the date, it is just formatting the document, so does not change this.

[jyn514]

Unless I'm mistaken this is an error with your date value and not to do with parsing the field. The supported date formats are YYYY-MM-DD and RFC3339.

These are valid YAML formats, so if zola is unable to parse them that means it's YAML parser isn't compliant with the specification. I'm not sure why Zola chose to use a custom date parser instead of the types that are built-in to both toml and yaml. See Dates and Times on https://toml.io/en/ and https://yaml.org/type/timestamp.html.

The field should also not be quoted.

In YAML the quotes don't have any effect in this context, they are syntactically the same.

[Kidsan]

@jyn514 Apologies if I was unclear, you are providing valid yaml, and zola treats it as valid yaml, but the date format that zola accepts is scoped to the ones I mentioned. I would think supporting other date formats is an enhancement. Perhaps a maintainer can shed more light on this.

[Keats]

I'm not sure why Zola chose to use a custom date parser instead of the types that are built-in to both toml and yaml.

A long time ago, you could put dates like date = "2022-01-01" in your front-matter and it would work. To make the transition smooth with the existing datetime from toml, we added a custom deserializer that tries to convert the string to a toml datetime if we get one.
We just need to handle the YAML datetime in that custom deserializer, it should be a few lines (tests not included) I hope?

[Keats]

Nevermind it's not that easy, I forgot how bad YAML is. No date type.
We should just document that the following formats are accepted for YML:

        // 0000-00-00T00:00:00.00Z
        // 0000-00-00T00:00:00.00
        // 0000-00-00
        // 00:00:00.00

[jyn514]

Hmm, I thought yaml had a datetime type but looking at https://docs.rs/serde_yaml/latest/serde_yaml/enum.Value.html it looks like it's not supported by serde unfortunately.

[Raymi306]

https://yaml.org/type/timestamp.html mentioned above has a regex for parsing the various components of the timestamp. If there is still interest in supporting these timestamps I can take a stab at it

[Keats]

I think it will depend on how complex the PR will be since we will need to massage those strings into a chrono datetime.

[Raymi306]

([0-9]{4})-([0-9][0-9]?)-([0-9][0-9]?)([Tt]|[ \t]+)([0-9][0-9]?):([0-9][0-9]):([0-9][0-9])(\.[0-9]*)?Z?([ \t]([-+][0-9][0-9]?)(:([0-9][0-9]?))?Z?|([-+][0-9][0-9])?:([0-9][0-9])?)?|([0-9]{4})-([0-9][0-9])-([0-9][0-9])

The regex did not work for me from the yaml document, this one is lightly modified with capture groups added, some reordering of |'s, and a new group to handle one of the cases.

I need more tests 🙃

edit:
I have some Rust Playground code that can take all of the example strings from the yaml spec and parse them into chrono datetimes. I think tomorrow I will move it into my zola fork and try and wire everything up. The code is a bit...wordy to say the least

[proofy]

By writing a converter from Wordpress to zola, I get an error with a RFC3339 compatible date like "2019-06-13T06:46:30+0000"
So zola can only handle the Zulu Format of RFC3339?

String to Datetime converting are always difficult with different programming languages (I use python for my Q&D converter, so it is XML to python to rust to yaml).
For what Zola needs the exact time?
If the date is formatted from year to second, String-sorting should be good enough.

[Keats]

Zola doesn't need the exact time. If you use a TOML front-matter you can use whatever format TOML is supporting. The issue is with YAML support that has a buggy code path since it was not handled when YAML support was added.