vcp: imply dates should also imply tz if needed

[tantek]

In http://microformats.org/wiki/value-class-pattern#microformats2_parsers

Add:

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

[tantek]

Use-case: https://indieweb.org/This_Week_in_Google where timezone is specified explicitly on the dt-start but not the dt-end.

http://pin13.net/mf2/?url=https://indieweb.org/This_Week_in_Google provides (partial result)

"start": [
"2014-09-11 13:30-0700"
],
"end": [
"2014-09-11T15:30"
]

Whereas it should say:

"start": [
"2014-09-11 13:30-0700"
],
"end": [
"2014-09-11 15:30-0700"
]

(note the "T" to " " change in separator for the dt-end property parsed result is already resolved by http://microformats.org/wiki/microformats2-parsing-issues#parsing_a_dt-_property )

[gRegorLove]

microformats/php-mf2#131 adds this.

[sknebel]

I have missed this occasionally when editing events on the IndieWeb wiki.

On the other hand, I also see the issue that it then becomes impossible to specify a time without TZ if any other property of the microfromat contains a time with TZ. This could cause problems e.g. on h-events which have dt-start/dt-end but also dt-published/dt-updated (the latter often being automatically generated). The parsing spec doesn't give use the ability to limit implied TZs to the same "category" of property, this would have to be a feature of the consuming applications and/or some kind of additional standardized processing algorithm.

I'm unsure if this is an important scenario, but we'd break it with this change.

[gRegorLove]

This is implemented in php-mf2 since v0.4.0. I realize I did not first "broaden implementer consensus" per change control -- apologies for that.

I think next steps before spec update are: broaden consensus, no objections, and explicit positive opinions by 2+ implementers.

[kartikprabhu]

I am completely ambivalent about this. Can be added to mf2py if it makes into spec.

[Zegnat]

I know I could only come up with a single objection to this, which I can’t track down right now, so I’ll put it in here for discussion. It also applies to the current implying of dates, but I didn’t see that as much of a problem as most things will likely include a date anyway.

This change could hinder people using floating date-times on anything that gets published to an h-feed with a dt-published. (Or outside h-feeds, of course, but a feed is a good reason why someone may add published date meta data.) As previously noted, we already have examples of events with dt-published (cf. microformats/h-event#2 (comment)).

If I wanted to (re)post the HWC event to my blog, where a dt-published with my local time zone is included, I can only do that by specifically not using vcp at all. Otherwise the HWC event (same time in multiple time zones) ends up getting pinned to my local time zone. This in turn means I cannot do a verbatim repost of the HWC event page, as that uses vcp.

[snarfed]

a proposal would be to implement this anyway, and note in the spec that this last comment's use case is a known flaw, but accept it anyway because it's outweighed by the benefit.

(i don't actually care personally, just noting this proposal.)

[Zegnat]

I think it was interesting that – without having read this issue – @snarfed raised this flaw at the Microformats parsing & vocabs, issues, proposals session at IndieWeb Summit 2018. Definitely makes me think there is something there, but it is hard to pin down. Probably because this flaw builds on very specific circumstances:

1. there must be several dt-* properties within the current object, of which at least one includes a pinned time zone, and
2. the author wants a dt-* property that uses vcp to be a floating time (a time without time zone).

Is this a case where we should follow in the footsteps of implied properties and just make it a lot more specific to address a specific use-case?

• if parsing a dt-start property results in a time without time zone, then:
  • if a dt-end property exists on the same microformat and has a time zone, adopt that time zone,
  • else the property has no time zone (it has a floating time).
• if parsing a dt-end property results in a time without time zone, then:
  • if a dt-start property exists on the same microformat and has a time zone, adopt that time zone,
  • else the property has no time zone (it has a floating time).

It makes sense to me to have dt-start and dt-end sync their time zones. It makes less sense to me to have other timestamps such as dt-updated have any effect on other properties. (I might even update from a different time zone than the post was originally published from or was targetting!)

[gRegorLove]

+1 for @Zegnat's proposal

See my newer comment below

[dshanske]

Agree with @Zegnat. If someone wants to specify something that starts in one timezone and ends in another, it should be specified on each.

[gRegorLove]

I'm revisiting this after @tantek mentioned it in chat.

At the end of https://microformats.org/wiki/value-class-pattern#microformats2_parsers_implied_date, it says

Note: This results in a similar enough implementation/interpretation as the previous vocabulary dependent heuristics for hAtom and hCalendar that a microformats2 parser can produce similar results for h-entry and h-event without having to know about their specific dt-* properties.

I initially +1 to @Zegnat's proposal because it seems to preserve publishers' intent and reduce unintended parsing side effects. Re-thinking it today, I realized it would move parsers "back" by requiring them to be aware of specific vocabularies and handle them in special ways. It does seem like something where the cases could grow over time if new dt-* properties are used.

I'm leaning towards the initial proposal, perhaps with a caveat like #4 (comment). I don't love the unintended side effect, though I wonder how often that will happen in the wild. The main examples in our discussion were the former indieweb.org/events, but that's been superseded by events.indieweb.org which doesn't have the issue.