dtend-issue - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:21:48Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:21, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~dtend-issue~~</entry-title>~~		{{DISPLAYTITLE:dtend-issue}}
	An [[hCalendar]] issue.		An [[hCalendar]] issue.

Tantek: additional examples / Add to Google Calendar link, fix trim use

2019-08-30T23:41:55Z

additional examples / Add to Google Calendar link, fix trim use

← Older revision		Revision as of 23:41, 30 August 2019
Line 3:		Line 3:

	;shortlink		;shortlink
	:http://tr.im/dtendi		:http://ufs.cc/w/dtendi

	== summary ==		== summary ==
Line 125:		Line 125:
	== origins ==		== origins ==
	This issue was raised to me (Tantek) in person pretty much since the first time I gave such an example back in 2004, was something I had to explicitly cover and point out in nearly every microformats [[presentation]] I gave, was eventually pointed out on the microformats discuss mailing list (citation needed), and eventually explicitly documented as an issue on the wiki [[hcalendar-issues]] page by Andy Mabbett on 2007-01-20.		This issue was raised to me (Tantek) in person pretty much since the first time I gave such an example back in 2004, was something I had to explicitly cover and point out in nearly every microformats [[presentation]] I gave, was eventually pointed out on the microformats discuss mailing list (citation needed), and eventually explicitly documented as an issue on the wiki [[hcalendar-issues]] page by Andy Mabbett on 2007-01-20.

			== additional examples ==
			=== Add to Google Calendar link ===
			Google Calendar’s special URL syntax for adding an event re-uses the iCalendar RFC dtend semantics which causes confusion for those authoring such URLs:
			* https://support.google.com/calendar/forum/AAAAd3GaXpEeBIPRtDf3Tg/?hl=en&gpf=d/topic/calendar/eBIPRtDf3Tg

			Aside: for more on "Add to Calendar" in general, see:
			* https://indieweb.org/Add_to_Calendar

	== see also ==		== see also ==

Tantek: /* summary */ update summary to reflect summary of resolution of issue, and update original issue summary with past tense and more explanatory language.

2010-03-06T01:36:21Z

summary: update summary to reflect summary of resolution of issue, and update original issue summary with past tense and more explanatory language.

@@ Line 6: / Line 6: @@
 == summary ==
-The [[hCalendar]] dtend property as of hCalendar 1.0 requires that end *dates* be marked up as occuring a whole day after what people typically consider the end date of an event.
+Authors typically publish the end date of a multi-day event as the last day the event occurs.  This is called an ''inclusive'' end date.
-E.g. if a conference starts on 2010 March 12th and ends 2010 March 16th, then the dtend must be marked up with the value of "2010-03-17" - seemingly a whole day after the end of the conference. hCalendar suggests obscuring this disparity between the human visible end date and the machine specified date using the <code><nowiki><abbr></nowiki></code> tag:
+Unfortunately the [[iCalendar]] standard requires publishing the day *after* the the last day of a multi-day event.  This is called an ''exclusive'' end date.
 <source lang=html4strict>
 <div class="vevent">
@@ Line 17: / Line 38: @@
 </div>
 </source>
-This is due to hCalendar being originally specified with the same semantics as iCalendar, which places that requirement on the DTEND property of the VEVENT object.
+The burden of handling this difference is place upon hCalendar-to-iCalendar converters, rather than content authors and publishers, per the [[principle]] of humans (authors) first, parsers (machines) second.
 == problems ==

Tantek: /* dtend inclusive whole dates */ strongly emphasize existing examples area, note upcoming.org according to Kaply

2010-01-06T01:37:39Z

dtend inclusive whole dates: strongly emphasize existing examples area, note upcoming.org according to Kaply

← Older revision		Revision as of 01:37, 6 January 2010
Line 37:		Line 37:
	** Advantage: Zero impact on vocabulary.		** Advantage: Zero impact on vocabulary.
	** Advantage: No increase to hCalendar authoring complexity.		** Advantage: No increase to hCalendar authoring complexity.
	** Advantage: Will reflect dominant use of dtend in examples in the wild (more research and citations needed to back this up!). In other words, authors have ALREADY been using dtend assuming it works this way (inclusive end dates), and will actually be surprised to find out that it doesn't. Making this change to DTEND semantics may actually reflect hCalendar publishing reality more than keeping the precise iCalendar DTEND semantic. Examples of inclusive dtend usage in the wild:		** Advantage: Will reflect dominant use of dtend in examples in the wild (more research and citations needed to back this up!). In other words, authors have ALREADY been using dtend assuming it works this way (inclusive end dates), and will actually be surprised to find out that it doesn't. Making this change to DTEND semantics may actually reflect hCalendar publishing reality more than keeping the precise iCalendar DTEND semantic. <strong id="existing-inclusive">Examples of inclusive dtend usage in the wild:</strong>
	*** http://barcamp.org/ - BarCamp wiki, dates for BarCamps		*** http://barcamp.org/ - BarCamp wiki, dates for BarCamps
	*** [[event\|microformats.org/wiki/events/]] - several multi-day event listings, as recently as Glenn Jones (who himself is a ''very'' knowledgable and prolific microformats developer) [[events/2010-03-12-sxsw\|event page for SXSW 2010]] use inclusive DTENDs (notably, using a span element that does NOT duplicate content).		*** [[event\|microformats.org/wiki/events/]] - several multi-day event listings, as recently as Glenn Jones (who himself is a ''very'' knowledgable and prolific microformats developer) [[events/2010-03-12-sxsw\|event page for SXSW 2010]] use inclusive DTENDs (notably, using a span element that does NOT duplicate content).
	*** draft of Emily Lewis' book <cite>Microformats Made Simple</cite>, uses dtend for inclusive end dates.		*** draft of Emily Lewis' book <cite>Microformats Made Simple</cite>, uses dtend for inclusive end dates.
	*** microformats.org co-founder and expert [http://simplebits.com/ Dan Cederholm's home page] has an events calendar that uses inclusive dtend dates.		*** microformats.org co-founder and expert [http://simplebits.com/ Dan Cederholm's SimpleBits home page] has an events calendar that uses inclusive dtend dates.
			*** http://upcoming.org (apparently - according to Michael Kaply)
	*** ... more instances of existing use of DTEND for inclusive end dates.		*** ... more instances of existing use of DTEND for inclusive end dates.
	** Advantage: Some number of implementations treat DTEND dates as inclusive (technically these are violating the current hCalendar spec, but they may be doing so deliberately to reflect actual hCalendar publishing practices). Implementations		** Advantage: Some number of implementations treat DTEND dates as inclusive (technically these are violating the current hCalendar spec, but they may be doing so deliberately to reflect actual hCalendar publishing practices). Implementations

Tantek: shortlink

2009-11-30T03:54:25Z

shortlink

← Older revision		Revision as of 03:54, 30 November 2009
Line 1:		Line 1:
	<entry-title>dtend-issue</entry-title>		<entry-title>dtend-issue</entry-title>
			An [[hCalendar]] issue.

	~~An [[hCalendar]] issue~~.		;shortlink
			:http://tr.im/dtendi

	== summary ==		== summary ==

	The [[hCalendar]] dtend property as of hCalendar 1.0 requires that end dates be marked up as occuring a whole day after what people typically consider the end date of an event.		The [[hCalendar]] dtend property as of hCalendar 1.0 requires that end dates be marked up as occuring a whole day after what people typically consider the end date of an event.

Tantek: /* possible solutions */ split with headings for easier reference/permalinking, resorted with resolution at top, test case

2009-11-30T03:38:50Z

possible solutions: split with headings for easier reference/permalinking, resorted with resolution at top, test case

@@ Line 30: / Line 30: @@
 As noted in the [[hcalendar-issues#issues_2007|issue description]] on the hCalendar issues page, there are at least a couple of possible solutions.
 <div class="discussion">
-* '''new hCalendar 1.0.1 property for end dates'''. As noted in the first resolution of the issue, we could introduce a new property, '''dtlast''' (described more in [[hcalendar-brainstorming#dtlast|hCalendar brainstorming: dtlast]]) which authors would use to specify the ''last'' day of an event, instead of dtend.
+* '''redefine hCalendar 1.0.1 dtend to be inclusive for whole dates'''.
 ** Advantage: Zero impact on vocabulary.
 ** Advantage: No increase to hCalendar authoring complexity.
@@ Line 68: / Line 60: @@
 *** +1 I agree with MatthewLevine. Those who follow hCalendar development are likely to make the change to inclusive dates, and those who don't are likely using inclusive dates already. [[User:Chris Cressman|Chris Cressman]]
 *** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
 * ... other possible solutions?
 </div>

Chris Cressman: Added my opinion to support inclusive dates.

2009-09-02T20:39:46Z

Added my opinion to support inclusive dates.

← Older revision		Revision as of 20:39, 2 September 2009
Line 66:		Line 66:
	*** +1 The natural human way to think about dates is inclusively; if the dtend date and dtstart date are equal, that clearly doesn't imply zero duration. The microformats principle of making things easier for authors rather than parser writers wins here [[User:Kevin Marks\|Kevin Marks]]		*** +1 The natural human way to think about dates is inclusively; if the dtend date and dtstart date are equal, that clearly doesn't imply zero duration. The microformats principle of making things easier for authors rather than parser writers wins here [[User:Kevin Marks\|Kevin Marks]]
	*** +1 It is much easier to migrate the limited number of tools and authors who already grok hCalendar 1.0 than to migrate publisher intuition. [[User:MatthewLevine\|MatthewLevine]]		*** +1 It is much easier to migrate the limited number of tools and authors who already grok hCalendar 1.0 than to migrate publisher intuition. [[User:MatthewLevine\|MatthewLevine]]
			*** +1 I agree with MatthewLevine. Those who follow hCalendar development are likely to make the change to inclusive dates, and those who don't are likely using inclusive dates already. [[User:Chris Cressman\|Chris Cressman]]
	*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)		*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
	* ... other possible solutions?		* ... other possible solutions?

MatthewLevine: /* possible solutions */ Added +1 to hCalendar 1.0.1

2009-08-29T19:48:41Z

possible solutions: Added +1 to hCalendar 1.0.1

← Older revision		Revision as of 19:48, 29 August 2009
Line 65:		Line 65:
	*** +1 Though I'm worried about tools catching up to this change. [[User:EdwardOConnor\|Ted]]		*** +1 Though I'm worried about tools catching up to this change. [[User:EdwardOConnor\|Ted]]
	*** +1 The natural human way to think about dates is inclusively; if the dtend date and dtstart date are equal, that clearly doesn't imply zero duration. The microformats principle of making things easier for authors rather than parser writers wins here [[User:Kevin Marks\|Kevin Marks]]		*** +1 The natural human way to think about dates is inclusively; if the dtend date and dtstart date are equal, that clearly doesn't imply zero duration. The microformats principle of making things easier for authors rather than parser writers wins here [[User:Kevin Marks\|Kevin Marks]]
			*** +1 It is much easier to migrate the limited number of tools and authors who already grok hCalendar 1.0 than to migrate publisher intuition. [[User:MatthewLevine\|MatthewLevine]]
	*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)		*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
	* ... other possible solutions?		* ... other possible solutions?

Kevin Marks: /* possible solutions */ yes for inclusive dates

2009-08-27T15:54:50Z

possible solutions: yes for inclusive dates

← Older revision		Revision as of 15:54, 27 August 2009
Line 64:		Line 64:
	*** +1 The spec should reflect the intuitive publishing behaviour (inclusive end dates). Humans first. —[[User:Adactio\|Jeremy Keith]]		*** +1 The spec should reflect the intuitive publishing behaviour (inclusive end dates). Humans first. —[[User:Adactio\|Jeremy Keith]]
	*** +1 Though I'm worried about tools catching up to this change. [[User:EdwardOConnor\|Ted]]		*** +1 Though I'm worried about tools catching up to this change. [[User:EdwardOConnor\|Ted]]
			*** +1 The natural human way to think about dates is inclusively; if the dtend date and dtstart date are equal, that clearly doesn't imply zero duration. The microformats principle of making things easier for authors rather than parser writers wins here [[User:Kevin Marks\|Kevin Marks]]
	*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)		*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
	* ... other possible solutions?		* ... other possible solutions?

EdwardOConnor: +1

2009-08-27T15:19:08Z

← Older revision		Revision as of 15:19, 27 August 2009
Line 63:		Line 63:
	*** +1 This appears logical and intuitive. We are effectively saying that end dates such as <code>DTEND</code> should parse to <code>YYYY-MM-DDT24:00:00</code>, and not <code>YYYY-MM-DDT00:00:00</code>. Seems simple, and entirely logical from a publishing stand —[[User:BenWard\|BenWard]] 08:18, 27 August 2009 (UTC)		*** +1 This appears logical and intuitive. We are effectively saying that end dates such as <code>DTEND</code> should parse to <code>YYYY-MM-DDT24:00:00</code>, and not <code>YYYY-MM-DDT00:00:00</code>. Seems simple, and entirely logical from a publishing stand —[[User:BenWard\|BenWard]] 08:18, 27 August 2009 (UTC)
	*** +1 The spec should reflect the intuitive publishing behaviour (inclusive end dates). Humans first. —[[User:Adactio\|Jeremy Keith]]		*** +1 The spec should reflect the intuitive publishing behaviour (inclusive end dates). Humans first. —[[User:Adactio\|Jeremy Keith]]
			*** +1 Though I'm worried about tools catching up to this change. [[User:EdwardOConnor\|Ted]]
	*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)		*** ... please add your +1/0/-1 opinion here and sign with three tildas (<nowiki>~~~</nowiki>)
	* ... other possible solutions?		* ... other possible solutions?