Open gRegorLove opened 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?)
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
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/)
+1 for normalised to YYYY-MM-DD
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:
The specification lists ordinal date format
YYYY-DDD
as a validvalue
.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:If it should be preserved, I'd recommend we add some examples to that list.