Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vcp: Clarify ordinal dates in parsed result #27

Open
gRegorLove opened this issue Mar 14, 2018 · 4 comments

Comments

Projects
None yet
4 participants
@gRegorLove
Copy link
Member

commented Mar 14, 2018

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

This comment has been minimized.

Copy link
Member

commented Mar 14, 2018

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

This comment has been minimized.

Copy link
Member

commented Mar 25, 2018

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

This comment has been minimized.

Copy link
Member

commented Mar 25, 2018

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

This comment has been minimized.

Copy link
Member

commented Mar 25, 2018

+1 for normalised to YYYY-MM-DD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.