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):

https://github.com/11ty/eleventy/blob/65d8d6d0102d18c4ada51b03351bb1032a0f95f2/src/Template.js#L744-L756

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 https://github.com/moment/luxon/issues/70 using fromSQL is what 11ty needs to call.

[zachleat]

867 fixes this.