Date a11y and i18n

[almereyda]

The section on Date formatting is ambiguous about how to format a date string:

Date formatting

Non-ISO8601 dates default to American formatting (Month/Day/Year). This can be changed to European formatting by adding the following line in the header area (before any event):

dateFormat: d/M/y

This is a hardcoded line, any other format attempt will not work.

The question is:

• Is it imaginable to change this into other representations as well?
  Thinking of the actual European d.M.y ;) (d/M/y is rather very British), or "short" ISO y-M-d, which many like, too.

If there'd be some kind of Markup for dates. such as []: or similar, one could also consider adding one or both of

• https://date-fns.org/
• https://momentjs.com/

[kochrt]

Admittedly yes the current implementation is very telling of how American I am 😂, I do apologize.

Is it imaginable to change this into other representations as well?

It is imaginable! I use luxon for parsing, it should be possible to provide other date formats. The European (or, as I'm learning, British) format was requested first, so I did that simple implementation first.

Markup for dates is also an interesting idea, I'll have to think about what that would look like. I want to balance ease of use for a first time user with more powerful features like what you're describing. A lot of dates would require a lot of markup though, I'd probably lean towards an expanded header entry for dateFormat. Maybe you could specify by precedence?

dateFormat: "d.M.y" "d/M/y" "MMMM d yyyy"

[almereyda]

Ah yes! Luxon already has built-in support for international datetime strings. Eventually one could also expose that locale feature to a configuration setting?

Also extending the parser to allow other datetime format signatures seems useful.

Yet especially it's fromISO method seems powerful, if one wanted to go into some kind of strict, yet flexible parsing mode, which could also make up for "short" ISO above.

A markup might only be needed, if no other syntactic convention can be found, such as:

All the characters before the first : (colon) in a line make up a datetime string.

I just wanted to consider datetimes here which contain spaces, why some kind of delimiter or interval marker seemed useful.

[kochrt]

So the problem here is that luxon can parse individual dates pretty well; unfortunately we can specify both individual dates and ranges in markwhen.

I thought it might be as simple as

let date;
if (strictDateFormat) {
  date = luxon.parseDate(dateString, strictDateFormat)
} else {
  // parse using our other techniques
}

but even if we specify our strictDateFormat like YYYY MM DD, if we came across 2022 03 01 - 2023 04 08 we still need to split the string in two to parse the start and end times.

Right now I'm using a lot of regex to get the appropriate strings, and I can do that because I've already decided which date formats are parseable. But as soon as I introduce arbitrary date formats to parse, my regex doesn't work anymore.

[cormacrelf]

Re ISO 8601 as brought up on HN, I agree and would like to see the standard ranges feature of ISO 8601-1, also known as EDTF (https://www.loc.gov/standards/datetime/). Because the separator appears to be hard-coded as -, and you're looking for dates on either side, that not only precludes straight up ISO 8601-style --separated single dates but also its /-separated range syntax (i.e. 2002/2003-08 for a range starting in 2002 and ending in August 2003).

My advice would be to have the first if-branch be "is this a valid EDTF, including possibly a /-separated range" and otherwise look for your hyphenated ranges. The four-digit year requirement of EDTF will, I think, avoid any kind of collisions with various MM/YYYY-MM/YYYY syntaxes etc.. The EDTF standard is pretty darn good, and frankly a perfect match for this use case. I understand the other more fun syntaxes, but EDTF is about as good as it gets in unambiguous computer+human readable/writable date format for ranges and Markwhen supporting a format with its characteristics seems pretty crucial to me.

[kochrt]

@cormacrelf I was unaware of the EDTF standard, but I agree, it seems a perfect fit. I have implemented it upstream and it is live on the site, let me know if you encounter any issues with it.