microformats / microformats2-parsing

For collecting and handling issues with the microformats2 parsing specification: http://microformats.org/wiki/microformats2-parsing
14 stars 6 forks source link

vcp: Clarify ordinal dates in parsed result #27

Open gRegorLove opened 6 years ago

gRegorLove commented 6 years ago

The specification lists ordinal date format YYYY-DDD as a valid value.

If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid, and the parser assembles the overall datetime value by concatenating the specific date, " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).

My reading of this^ section is the ordinal date format should be preserved in the assembled datetime. I wanted to confirm that's correct, though, since the only results listed are YYYY-MM-DD variants:

  • YYYY-MM-DD - no time specified
  • YYYY-MM-DD HH:MM or YYYY-MM-DD HH:MM:SS - time specified but no timezone. This is a floating time.
  • YYYY-MM-DD HH:MMZ or YYYY-MM-DD HH:MM:SSZ or
  • YYYY-MM-DD HH:MM-XXYY or YYYY-MM-DD HH:MM:SS-XXYY or
  • YYYY-MM-DD HH:MM+XXYY or YYYY-MM-DD HH:MM:SS+XXYY - both time and timezone offset were specified.

If it should be preserved, I'd recommend we add some examples to that list.

Zegnat commented 6 years ago

I think it should indeed be preserved. Where you discover the specific date value earlier it explicitly says to “then use that as the date value”:

  • if the value has *only* a specific date, specifically, fits the following ISO8601 date patterns (i.e. as documented in the Wikipedia summary of ISO8601)
    • YYYY-MM-DD
    • YYYY-DDD
    • then use that as the date value. For the purposes of the value class pattern, the hyphens "-" separating the year, month, day and/or ordinal day are required.

So if you found YYYY-DDD then that exact string should be “the date value” that gets concatenated. Unless “the specific date” mentioned in the concat paragraph is somehow different from “the date value” during discovery. (Would it help to normalise these terms to always be the same?)

kartikprabhu commented 6 years ago

Current status of parsers

Go: accepts ordinal dates and converts to MM-DD in the final output. Ruby: accepts ordinal dates but does not convert to MM-DD php-mf2: does not accept ordinal dates mf2py: does not accept ordinal dates mf2py (experimental): accepts ordinal dates but does not convert to MM-DD (edit: updated to convert to MM-DD ) Node: accepts ordinal dates but does not convert to MM-DD

tantek commented 6 years ago

The list of possible VCP assembled output syntaxes was intended to be comprehensive. Thus ordinal ISO dates should be normalized to YYYY-MM-DD. The spec should be explicit about this since it appears parsers disagree.

Assembled dates must be normalized YYYY-MM-DD, because parsed output consuming code likely expects that, either way, simpler for JSON consuming code.

(Originally published at: http://tantek.com/2018/084/t4/)

kartikprabhu commented 6 years ago

+1 for normalised to YYYY-MM-DD

gRegorLove commented 2 years ago

Proposed text:

Change this line:

  • If by parsing the "value" element(s), at least a specific date has been found, then the "value" is overall valid, and the parser assembles the overall datetime value by concatenating the specific date (PROPOSED: normalized to YYYY-MM-DD), " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).

To: