FR: better date parsing in front matter

[hidegh]

Describe the bug
Time zone information in the front matter inside a date results in an error, if it's entered as below. Other frameworks (HUGO, HEXO, JEKYLL) were more flexible.

I do understand that the format 2019-08-08 14:10:00 +0800 is not a standard, but it's very readable (human like). So it should be accepted/preferred over the 2019-08-08T14:10:00+0800.

Below is the front matter and error it produces, for the non-standardly formatted date.

---
title: Writing a New Post
author: Cotes Chung
date: 2019-08-08 14:10:00 +0800
categories: [Blogging, Tutorial]
tags: [writing]
---

The error is:

> date front matter value (2019-08-08 14:10:00 +0800) is invalid for ./src/posts/toc/2019-08-08-write-a-new-post.md

`Error` was thrown:
    Error: date front matter value (2019-08-08 14:10:00 +0800) is invalid for ./src/posts/toc/2019-08-08-write-a-new-post.md
        at Template.getMappedDate (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\Template.js:689:19)
        at async Template.addPageDate (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\Template.js:277:19)
        at async Template.getData (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\Template.js:258:20)
        at async Template.getTemplateMapEntries (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\Template.js:744:16)
        at async TemplateMap.add (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\TemplateMap.js:32:21)
        at async Promise.all (index 19)
        at async TemplateWriter._createTemplateMap (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\TemplateWriter.js:169:5)
        at async TemplateWriter.writeTemplates (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\TemplateWriter.js:203:5)
        at async TemplateWriter.write (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\TemplateWriter.js:254:25)
        at async Eleventy.write (C:\$_Work\jamstack-eleventy-custom\node_modules\@11ty\eleventy\src\Eleventy.js:743:13)

To Reproduce
Use date in the format provided in this sample above.

Expected behavior
Flexible date parsing.

Screenshots
If applicable, add screenshots to help explain your problem.
N/A

Environment:

• OS and Version: W10
• Eleventy Version: 0.11.1

Additional context
N/A

[Ryuno-Ki]

Under the hood, Eleventy is using Luxon so it might be worth filling an issue with them, too.

[pdehaan]

Interesting. This seems to be parseable in JavaScript w/ ye olde Date constructor:

const d = new Date("2019-08-08 14:10:00 +0800");
console.log(d); // Wed Aug 07 2019 23:10:00 GMT-0700 (Pacific Daylight Time)

But it doesn't look like Luxon's .fromISO() likes that specific format (which is probably fair since it probably isn't a valid ISO date format):

eleventy/src/Template.js

Lines 744 to 756 in 65d8d6d

	// try to parse with Luxon
	let date = DateTime.fromISO(data.date, { zone: "utc" });
	if (!date.isValid) {
	throw new Error(
	`date front matter value (${data.date}) is invalid for ${this.inputPath}`
	);
	}
	debug(
	"getMappedDate: Luxon parsed %o: %o and %o",
	data.date,
	date,
	date.toJSDate()
	);

This seemed to work in RunKit, converting to a temp Date object and then passing d.toISOString() to Luxon's static DateTime.fromISO() method:

const {DateTime} = require("luxon");

const d = new Date("2019-08-08 14:10:00 +0800");
let date = DateTime.fromISO(d.toISOString(), { zone: "utc" });
if (!date.isValid) {
  throw new Error(
    `date front matter value (x) is invalid for y`
  );
}
console.log(date);

So I'm guessing it isn't really a bug in Luxon and 11ty needs to try parsing the date before passing it off to Luxon, or, just don't put spaces in your date formats.

[hidegh]

Thanx guys, based on luxon's docs moment/luxon#70 using fromSQL is what 11ty needs to call.

[zachleat]

#867 fixes this.