Time element - Revision history

Pigsonthewing: /* noon and midnight */ c

2022-07-10T11:55:25Z

noon and midnight: c

← Older revision		Revision as of 11:55, 10 July 2022
Line 433:		Line 433:

	'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.		'''Answer:''' This proposal does not address the (English) language specific terms of "noon" and "midnight". Proposal clarified to explicitly treat 12am as 00:00:00, and 12pm as 12:00:00.
			:The words "noon" and "midnight" may be specific to English (the language used on this page); the concepts are not. 00:00:00 is not "12am" and 12:00:00 is not "12pm". [[User:Pigsonthewing\|Andy Mabbett]] 11:55, 10 July 2022 (UTC)

	==== am pm i18n ====		==== am pm i18n ====

Pigsonthewing: /* am pm discussion */ c

2022-07-10T11:51:38Z

am pm discussion: c

← Older revision		Revision as of 11:51, 10 July 2022
Line 424:		Line 424:
	* 0(query) [[User:Pigsonthewing\|Andy Mabbett]] - see above for concerns over date formatting.		* 0(query) [[User:Pigsonthewing\|Andy Mabbett]] - see above for concerns over date formatting.
	** queries moved to am pm FAQ section with answers. - [[User:Tantek\|Tantek]] 16:57, 6 August 2010 (UTC)		** queries moved to am pm FAQ section with answers. - [[User:Tantek\|Tantek]] 16:57, 6 August 2010 (UTC)
			***Please do not rewrite or edit my comments. [[User:Pigsonthewing\|Andy Mabbett]] 11:51, 10 July 2022 (UTC)
	* ...		* ...
	</div>		</div>

Pigsonthewing: /* nested time discussion */ r

2022-07-10T11:49:42Z

nested time discussion: r

← Older revision		Revision as of 11:49, 10 July 2022
Line 328:		Line 328:
	* -1 [[User:Pigsonthewing\|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.		* -1 [[User:Pigsonthewing\|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.
	** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible world-wide per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek\|Tantek]]		** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible world-wide per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek\|Tantek]]
			***[Belated response, as I stopped following this site a long time ago (not least because of the snide and derogatory tone of some comments, of which the above is a fine example), and only revisited by chance]. Had I said "international readability is irrelevant", you might have a point. I did not, and you misquoted me. I actually said (emphasis added for clarity) "'international' readability is irrelevant, '''''when pages are otherwise in one language or another'''''". While YYYY-MM-DD format is relevant in a-lingual contexts such as code and data, ''when a page is in a specific language'' then the prose date ''in that language'' is the most accessible to its target audience (An example would be the use of "24 November 2011" on this page. In your own signature). Making the date accessible to readers of other languages - especially at the cost of reduced accessibility for the target audience - is irrelevant, if the reader cannot understand the surrounding text. Nor do I "assume Western bias". In this case, what I said was "accessible prose such as, say, '5 August 2010' or 'August 5th, 2010'". Note the inclusion of the phrase "such as, say", which indicates that the following examples are just that: ''examples''. I gave my examples in English, because discussion on this page is carried out in English. But what I said holds true if the date is written in Urdu, Mandarin, Arabic, Japanese, or any other specific language. I posit that 80% of the world do not use YYYY-MM-DD dates outside of special use cases such as those I mention; and still evidence to the contrary is lacking. Nor do I hold an "anti-internationalisation position" (assuming that is what you mean by the far from internationally accessible "i18n"). Once again, I must ask you not to attempt to speak for me. My objection stands. [[User:Pigsonthewing\|Andy Mabbett]] 11:49, 10 July 2022 (UTC)
	* +1 [[User:asbjornu\|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:		* +1 [[User:asbjornu\|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
	<pre><nowiki>		<pre><nowiki>

Javarome: Fuzzy durations

2014-11-26T12:32:36Z

Fuzzy durations

← Older revision		Revision as of 12:32, 26 November 2014
Line 499:		Line 499:
	** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.		** add an explicit 'duration' attribute to the time element for when the time element is used to represent a duration.
	** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.		** permit MM:SS and HH:MM:SS syntaxes for the 'duration' attribute. Note that the audio duration examples above all use the syntax "MM:SS" where MM can be 1-2 digits.
			* '''fuzzy durations'''.
			** [[User:Javarome\|Jérôme Beau]] As per fuzzy dates mentioned above, durations should allow fuziness in durations :<pre><nowiki><time datetime="P1H" certainty="P5M">one hour, more or less five minutes</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="P1H" certainty="P1M,P30S">one hour, up to 1 minute shorter or 30 seconds longer</time></nowiki></pre>
	</div>		</div>

Javarome: /* Fuzzy dates */

2014-11-26T11:34:04Z

Fuzzy dates

← Older revision		Revision as of 11:34, 26 November 2014
Line 72:		Line 72:
	* +1 [[User:Pigsonthewing\|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)		* +1 [[User:Pigsonthewing\|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
	**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.		**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
			* +1 [[User:Javarome\|Jérôme Beau]] provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :<pre><nowiki><time datetime="1855-06-18" certainty="P3D">around 18 June 1855</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time></nowiki></pre>
	* +1 [[User:eatyourgreens\|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)		* +1 [[User:eatyourgreens\|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)
	* 0 (comments) [[User:Tantek\|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:		* 0 (comments) [[User:Tantek\|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:

Tantek: impedance match new date time inputs was accepted (copy/moved accordingly), scoped remaining inputs to impedance match new time granularity proposal

2013-02-25T12:41:58Z

impedance match new date time inputs was accepted (copy/moved accordingly), scoped remaining inputs to impedance match new time granularity proposal

← Older revision		Revision as of 12:41, 25 February 2013
Line 18:		Line 18:
	All Date granularity proposals have been accepted. See: [[Time element accepted]].		All Date granularity proposals have been accepted. See: [[Time element accepted]].

	= HTML5 internal consistency =		== HTML5 internal consistency ==
	== impedance match new date time inputs ==		=== impedance match new date time inputs ===
	The time element should be able to represent every granularity of times and dates that the new date time <code><input></code> elements allow. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)		The proposal to impedance match new date time inputs was partially accepted (additional time element granularity). See: [[Time element accepted]].

			=== inputs to impedance match new time granularity ===
			While this could be documented on an [[input]] element page, it made sense to keep it here as it's a part of time element discussion.

			For each time element granularity, there should be a corresponding input element.

			The time element should be able to represent every granularity of times and dates that the new date time <code><input></code> elements allow and vice-versa. Here is a list of all the date time <code><input></code> elements along with the corresponding <code><time></code> element usage (if applicable)

	<pre><nowiki>		<pre><nowiki>
	<input type="date"> - <time>YYYY-MM-DD</time>		<input type="date"> - <time>YYYY-MM-DD</time>
	<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>		<input type="datetime"> - <time>YYYY-MM-DDTHH:MM:SS</time>
	<input type="month"> - <time>YYYY-MM</time> (as of 2011-11-18)		<input type="month"> - <time>YYYY-MM</time> (accepted as of 2011-11-18)
	<input type="week"> - <time>YYYY-Www</time> (as of 2011-11-18)		<input type="week"> - <time>YYYY-Www</time> (accepted as of 2011-11-18)
	<input type="time"> - <time>HH:MM:SS</time>		<input type="time"> - <time>HH:MM:SS</time>
	<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>		<input type="datetime-local"> - <time>HH:MM:SS-ZZ:YY</time>
	New proposed input elements:		New proposed input elements:
	<input type="year"> - <time>YYYY</time> (as of 2011-11-18)		<input type="year"> - <time>YYYY</time> (accepted as of 2011-11-18)
	<input type="month-day"> - <time>--MM-DD</time> (as of 2011-11-18)		<input type="month-day"> - <time>--MM-DD</time> (accepted as of 2011-11-18)
	</nowiki></pre>		</nowiki></pre>

	~~In particular the <code><time></code> element is missing support for the following date inputs:~~

	* input type="month" - this would be satisfied by the [[Time_element#year_month_only\|time element year month proposal]].
	* input type="week" - this would be satisfied by the [[Time_element#year_week_only\|time element year week proposal]].

	~~In addition, if the new proposed~~ [[input]] elements are ~~accepted,~~ the respective time element ~~support should be added as well~~:		The following [[input]] elements are proposed to represent the respective time element granularity:

	* input type="year" ~~- this would be satisfied by the [[Time_element#year_only\|time element year proposal]].~~		* input type="year"
	* input type="month-day" ~~- this would be satisfied by the [[Time_element#month_day_only\|time element month day proposal]].~~		* input type="month-day"

	<div class="discussion">		<div class="discussion">

Tantek: start moving accepted proposals to a new page

2013-02-15T20:38:30Z

start moving accepted proposals to a new page

Show changes

Tantek: /* Fuzzy dates */ changed flourished example to have a end date range and add WP citation

2013-02-15T20:13:58Z

Fuzzy dates: changed flourished example to have a end date range and add WP citation

← Older revision		Revision as of 20:13, 15 February 2013
Line 212:		Line 212:

	== Fuzzy dates ==		== Fuzzy dates ==
	The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580"), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.		The time element should accept ''fuzzy'' (uncertain, approximate) dates ("around 18 June 1855" "summer 1970", "circa December 1963", "flourished 1580-1600"[http://en.wikipedia.org/wiki/Basawan]), centuries, and allow eras ("Edwardian", "bronze age", "Jurassic") in a manner to be determined; perhaps once defined by EDTF efforts.

	;Use cases:		;Use cases:

Tantek: note change proposal for 'era'

2012-05-03T21:58:10Z

note change proposal for 'era'

← Older revision		Revision as of 21:58, 3 May 2012
Line 283:		Line 283:
	* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.		* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.
	* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.		* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.
			** See related: [http://www.w3.org/html/wg/wiki/User:Idevlin/add_era_attribute_to_time_element add era attribute to time element] change proposal

	= Syntax improvements =		= Syntax improvements =

Ian: /* Calendar scale related posts */

2012-02-13T08:57:22Z

Calendar scale related posts

← Older revision		Revision as of 08:57, 13 February 2012
Line 282:		Line 282:
	* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale		* [http://www.brucelawson.co.uk/2009/html-5-politics-and-me/ 2009-02-25 HTML 5, politics and me] blog post by Bruce Lawson - look for mention of "time element" which mentions: <blockquote cite="http://www.brucelawson.co.uk/2009/html-5-politics-and-me/">I see no reason why authors shouldn’t be able to mark up BCE dates... which are currently disallowed by the spec</blockquote> BCE dates are typically in the Julian (or other?) calendar and thus a request for BCE dates markup implies something at least like Calendar scale
	* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.		* [http://html5doctor.com/the-time-element/ 2010-02-09 The time element (and microformats)] blog post on HTML5 Doctor by Bruce Lawson - mentions: <blockquote>The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era.</blockquote> Again, seemingly implying a desire for non-Gregorian calendars as well.
			* Dates before the Christian/Common Era could be specified by adding an <code>era</code> attribute that can take two values: <code>CE</code> (Common Era) or <code>BCE</code> (Before Common Era). If the attribute isn't present, then a default value of <code>CE</code> is assumed. The [http://en.wikipedia.org/wiki/Calendar_era#Dionysian_.22Common_Era.22 Dionysian "Common Era"] doesn't have a "year 0" thus eliminating that potential issue.

	= Syntax improvements =		= Syntax improvements =

← Older revision		Revision as of 11:49, 10 July 2022
Line 328:		Line 328:
	* -1 [[User:Pigsonthewing\|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.		* -1 [[User:Pigsonthewing\|Andy Mabbett]] - Introduces excessive complexity on the apparent assumption that a significant proportion of dates in the wild (or even in microformats in the wild) use the format "2010-08-05" and not more human-readable and accessible prose such as, say, "5 August 2010" or "August 5th, 2010". No evidence (also supposedly required by the microformats "process") has been provided to show that this is the case. {If the apparent assumption is not made, then this fails 80/20.) '''Update''': Subsequent changes have addressed some of my concerns. The proposal to separate times from dates ''with datetime attributes'' is a better one. However, we still lack supporting evidence and I object to any wording in the spec which perpetuates the myth that YYYY-MM-DD dates are in any way "human-friendly/readable" compared to prose dates: "international" readability is irrelevant, when pages are otherwise in one language or another.
	** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible world-wide per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek\|Tantek]]		** Your statements assume Western bias (you mention 80/20, however note that 80% of the world is not Western). Your assertion of the readability of "5 August 2010" or "August 5th, 2010" assume Western consumers. In actuality, "2010-08-05" is more human-readable and accessible world-wide per international W3C expert study and report (presumably greater expertise than your opinions/assertions). Your assertion that "international readability is irrelevant" is discriminatory and intolerant. I urge you to reconsider your anti-i18n position. - [[User:Tantek\|Tantek]]
			***[Belated response, as I stopped following this site a long time ago (not least because of the snide and derogatory tone of some comments, of which the above is a fine example), and only revisited by chance]. Had I said "international readability is irrelevant", you might have a point. I did not, and you misquoted me. I actually said (emphasis added for clarity) "'international' readability is irrelevant, '''''when pages are otherwise in one language or another'''''". While YYYY-MM-DD format is relevant in a-lingual contexts such as code and data, ''when a page is in a specific language'' then the prose date ''in that language'' is the most accessible to its target audience (An example would be the use of "24 November 2011" on this page. In your own signature). Making the date accessible to readers of other languages - especially at the cost of reduced accessibility for the target audience - is irrelevant, if the reader cannot understand the surrounding text. Nor do I "assume Western bias". In this case, what I said was "accessible prose such as, say, '5 August 2010' or 'August 5th, 2010'". Note the inclusion of the phrase "such as, say", which indicates that the following examples are just that: ''examples''. I gave my examples in English, because discussion on this page is carried out in English. But what I said holds true if the date is written in Urdu, Mandarin, Arabic, Japanese, or any other specific language. I posit that 80% of the world do not use YYYY-MM-DD dates outside of special use cases such as those I mention; and still evidence to the contrary is lacking. Nor do I hold an "anti-internationalisation position" (assuming that is what you mean by the far from internationally accessible "i18n"). Once again, I must ask you not to attempt to speak for me. My objection stands. [[User:Pigsonthewing\|Andy Mabbett]] 11:49, 10 July 2022 (UTC)
	* +1 [[User:asbjornu\|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:		* +1 [[User:asbjornu\|Asbjørn Ulsberg]] - With nesting (and [http://en.wikipedia.org/wiki/ISO_8601#Time_intervals ISO-8601 time intervals]), the hCalendar example can be made more precise and less verbose like so:
	<pre><nowiki>		<pre><nowiki>

← Older revision		Revision as of 11:34, 26 November 2014
Line 72:		Line 72:
	* +1 [[User:Pigsonthewing\|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)		* +1 [[User:Pigsonthewing\|Andy Mabbett]] (Per use cases in "Extended Date Time Format" proposals & TEI - see external links)
	**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.		**Uncertainty possibly resolved by a "certainty" attribute: <pre><nowiki><time datetime="1855-06-18" certainty="3days">around 18 June 1855</time></nowiki></pre><pre><nowiki><time datetime="1970-06" certainty="45days">summer 1970</time></nowiki></pre>(with "45days" meaning "+/- 45 days" - in other words, a 90-day window, and similar allowance for year or other ranges; or: <pre><nowiki><time datetime="1963-12" certainty="circa">circa December 1963</time></nowiki></pre>with pre-defined prose values allowed, such as "flourished", "notbefore", "notafter", etc.
			* +1 [[User:Javarome\|Jérôme Beau]] provided that 'certainty' attribute use a standard format as well, such as the time duration syntax :<pre><nowiki><time datetime="1855-06-18" certainty="P3D">around 18 June 1855</time></nowiki></pre>Optionally, when uncertainty differ in past and future, a second, comma-separated duration should be interpreted as the specific future-incertainty.<pre><nowiki><time datetime="1855-06-18" certainty="P3D,P5D">around 18 June 1855, up to 3 days before or 5 days later</time></nowiki></pre>
	* +1 [[User:eatyourgreens\|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)		* +1 [[User:eatyourgreens\|Jim O'Donnell]] (Dates such as 'circa 1910' published on Flickr eg. [http://www.flickr.com/photos/nationalmaritimemuseum/4793356412/ The RNVR Training Ship 'Buzzard'…] also [http://www.flickr.com/photos/nationalmaritimemuseum/archives/ a list of fuzzy dates for a set of photos].)
	* 0 (comments) [[User:Tantek\|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration:		* 0 (comments) [[User:Tantek\|Tantek]] - Update: the syntax still seems a bit loose/imprecise, however, I appreciate the improvements being made. Some additional changes for consideration: