nodeca/js-yaml

2019-03-22 20:18:42 +0100 interpreted as a string

Closed this issue · 3 comments

2019-03-13 20:18:42 +0000 is a date format considered valid in Jekyll, when switching to 11ty, it's not. (see: 11ty/eleventy#413 (comment))

space separated: 2001-12-14 21:59:43.10 +0000 returns a string on https://nodeca.github.io/js-yaml/

http://www.yamllint.com/ will add a colon after parsing: 2019-03-13 20:18:42 +00:00

This package is about yml standard, not about jekyll. If you think js-yaml does not conform spec, please give URL to spec details. Also, reference implementation is pyyaml, if you need to compare.

Just found this and I've got to say, the spec is way to ambiguous on its definition of timestamps. YAML 1.2 §10.1. Failsafe Schema doesn't actually provide any guidance about what to do with Example 2.22 Timestamps even though it's implied that it shouldn't need an explicit tag. As an editor of other specs, I'd call this a spec bug, not just an implementation one. So congrats, you're both right!

I'm inclined to say we should defer to RFC 3339 Date and Time on the Internet: Timestamps §5.6 Internet Date/Time Format, which covers the canonical, iso8601 and date examples, but I really don't know what to do about spaced: 2001-12-14 21:59:43.10 -5. If it were me, I'd say allowing space would go from RFC 3339's:

   time-numoffset  = ("+" / "-") time-hour ":" time-minute
   time-offset     = "Z" / time-numoffset

   partial-time    = time-hour ":" time-minute ":" time-second
                     [time-secfrac]
   full-date       = date-fullyear "-" date-month "-" date-mday
   full-time       = partial-time time-offset

   date-time       = full-date "T" full-time

to instead have:

   full-time       = partial-time [" "] time-offset
   date-time       = full-date ("T" / "t" / " ") full-time

But then we don't either allow 2019-03-13 20:18:42 +0000 (no colon) or 2001-12-14 21:59:43.10 -5 (not even remotely close to a time-offset).

So I guess I'm off to speak with the editors!

Ah, looks like this example is likely to be removed: yaml/yaml-spec#268