Partially matching date pattern is accepted for dt.

[Zegnat]

Sorry for the cryptic title.

It looks like the parser does not require an exact match for ISO 8601 patterns to accept something as a valid date. This makes for really weird timestamps, and odd implied dates. Example:

<span class="h-event">
  <span class="dt-start">
    <span class="value" title="May 31, 2017">🐔 2017-05-31</span>
    <span class="value" title="17:30">17:30</span>
  </span>
  –
  <span class="dt-end">19:30</span>
</span>

Current output:

{
    "type": [
        "h-event"
    ],
    "properties": {
        "start": [
          "\ud83d\udc14 2017-05-31T17:30"
        ],
        "end": [
          "\ud83d\udc14 2017-05-31T19:30"
        ],
        "name": [
          "\ud83d\udc14 2017-05-31\r\n    17:30\r\n  \r\n  \u2013\r\n  19:30"
        ]
    }
}

The expected output does not include a T in start because it is not a valid ISO timestamp, it should just be a concatenation of the separate strings using “ ”. It also does not include any date info in end, as no other valid date has been found. That is:

{
    "type": [
        "h-event"
    ],
    "properties": {
        "start": [
          "\ud83d\udc14 2017-05-31 17:30"
        ],
        "end": [
          "19:30"
        ],
        "name": [
          "\ud83d\udc14 2017-05-31\r\n    17:30\r\n  \r\n  \u2013\r\n  19:30"
        ]
    }
}

[gRegorLove]

Lots of good date-parsing catches lately. :)

The regex used for this appears to be too lenient. It's checking the YYYY-MM-DD format but doesn't care about extra characters around it. I don't think it should be parsing the date value due to the chicken:

if the value has only a specific date, specifically, fits the following ISO8601 date patterns...

So when I make the regex more strict, it only finds the time portion of the dt-start. The final steps of the VCP algorithm make it sound like it's not valid without the date portion, so nothing should be parsed for dt-start:

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...

However, later on the VCP page is the note that seems to contradict that:

• if a dt-* property has a time but lacks a date
• then it adopts the date of the most recently seen dt-* property with a date in that microformat.
  • if no previous dt-* properties have a date,
  • then it adopts its date from the next dt-* property with a date seen in that microformat.
  • otherwise it simply has a time (and no date).

It seems the expected output should be:

{
    "items": [
        {
            "type": [
                "h-event"
            ],
            "properties": {
                "start": [
                    "17:30"
                ],
                "end": [
                    "19:30"
                ],
                "name": [
                    "\ud83d\udc14 2017-05-31\n    17:30\n  \n  \u2013\n  19:30"
                ]
            }
        }
    ],
    "rels": []
}

[Zegnat]

I took that same paragraph to mean that, because no valid date was found, it should revert to standard vcp parsing and concatenate the different values. Hmm…

What would happen if both the date and the time value featured a chicken? Would the value for start be an empty string, or would it then allow for invalid timestamp information?

I am mostly wondering how much datetime validation the mf2 parser is required to do. And whether we would also have to then apply that to non-vcp dt-* parsing.

[sknebel]

The wording indeed doesn't cover failure cases very well, but I'd agree with gRegorLove for this specific example: if http://microformats.org/wiki/value-class-pattern#microformats2_parsers overrides the wording further up on the page, then both should be parsed as datetimes, which end up having only a time.

Behavior if all components are invalid seems less defined to me. The VCP-dt algorithm doesn't clearly say what to do with components that don't fit the patterns, and the reassembly step doesn't trigger when it's conditions (at least some element found) are met. It kind of sounds like it should fall back to "normal" VCP assembly (concat all components, seperated by spaces). This would be different if it clearly said to ignore invalid components.

From quick testing yesterday, existing parsers vary in behavior here, another sign that this isn't clearly enough specified.

It is relevant for microformats/microformats2-parsing#8, but the key difference is that outside of vcp there are no multiple components to assemble, but the entire value has to fit/not fit some pattern, so the vcp case has aspects to be improved independently of that.

[gRegorLove]

If VCP returns no valid date or time part, I think instead of an empty value, there would be no start key in the parsed results. I think this makes it clearer there's been an error in the authoring and doesn't provide invalid values in the parsed results.

I'm not sure why VCP dt-* parsing seems to have stricter validation of formats than regular dt-* parsing. @tantek could answer that better.

[tantek]

Confused by the first example. class="value" != use 'title' attribute. If you want that see http://microformats.org/wiki/value-class-pattern#Parsing_value_from_a_title_attribute

[Zegnat]

Confused by the first example. class="value" != use 'title' attribute.

There were titles only because I copied @gRegorLove’s example HTML from an other issue. I was really only testing implied values and this issue is about running into something I did not expect. The chicken can be any label that breaks ISO date notation, maybe someone adds a day of the week:

<span class="h-event">
  <span class="dt-start">
    <span class="value">Wednesday 2017-05-31</span>
    <span class="value">17:30</span>
  </span>
  –
  <span class="dt-end">19:30</span>
</span>

The current PHP parser then adds the string “Wednesday 2017-05-31” as an implied date to dt-end, which I believe to be wrong.

After more (re-)reading of the VCP, I have changed my opinion on the expected output and agree with @gRegorLove and @sknebel. So we can consider this issue to be about including the faulty date part at all, not about implying a faulty date part to just the dt-end as I first believed.

Hope that clears up the focus of this issue, we can take our general VCP discussion to microformats/microformats2-parsing 😃

[gRegorLove]

@kartikprabhu pointed out that mf2py parses this as expected, so I think we're on the right track:

{
    "rels": {}, 
    "items": [
        {
            "type": [
                "h-event"
            ], 
            "properties": {
                "start": [
                    "17:30"
                ], 
                "end": [
                    "19:30"
                ], 
                "name": [
                    "Wednesday 2017-05-31\n17:30\n\r\n  –\r\n  19:30"
                ]
            }
        }
    ], 
    "rel-urls": {}
}

I'll keep an eye on this and the VCP discussion before making an update in php-mf2. It's a regex change so I want to be careful. :) So far I don't think this issue has happened to anyone, so that's good.

Also a note about the markup in the other issue: the only reason it's using VCP is because MediaWiki (or the installed version on indieweb.org, at least) doesn't support the preferred <time> element, so the one-day-event template had to use the more verbose VCP markup.

[aaronpk]

Is this a case where the regex should be matching exactly YYYY-MM-DD? Could be as easy as adding a ^ and $ to the regex to match the full string instead of allowing partial matches.

[aaronpk]

After merging #131 the parser now returns the result @gRegorLove pasted above. Is that the expected behavior? It is still not including the Wednesday 2017-05-31 part at all since that wasn't parsed as a valid timestamp. If so, we can close this issue.

[gRegorLove]

Double-checked and confirmed that this now parses the "Wednesday" example as expected, so closing:

{
    "items": [
        {
            "type": [
                "h-event"
            ],
            "properties": {
                "start": [
                    "17:30"
                ],
                "end": [
                    "19:30"
                ],
                "name": [
                    "Wednesday 2017-05-31\n    17:30\n  \n  \u2013\n  19:30"
                ]
            }
        }
    ],
    "rels": [],
    "rel-urls": []
}