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: imply dates should also imply tz if needed #4

Open tantek opened 8 years ago

tantek commented 8 years ago

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

Add:

tantek commented 8 years ago

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 commented 7 years ago

https://github.com/indieweb/php-mf2/pull/131 adds this.

sknebel commented 7 years ago

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 commented 6 years ago

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 commented 6 years ago

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

Zegnat commented 6 years ago

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. https://github.com/microformats/h-event/issues/2#issuecomment-308650834).

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 commented 6 years ago

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 commented 6 years ago

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?

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 commented 4 years ago

+1 for @Zegnat's proposal

See my newer comment below

dshanske commented 4 years ago

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 commented 2 years ago

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 https://github.com/microformats/microformats2-parsing/issues/4#issuecomment-400488451. 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.