value-class-pattern - Revision history

Tantek: /* Date and time parsing */ capture issue raised by jkingweb

2026-09-20T19:33:18Z

Date and time parsing: capture issue raised by jkingweb

← Older revision		Revision as of 19:33, 20 September 2026
Line 212:		Line 212:
	* YYYY-MM-DD HH:MM-XXYY or YYYY-MM-DD HH:MM:SS-XXYY or		* YYYY-MM-DD HH:MM-XXYY or YYYY-MM-DD HH:MM:SS-XXYY or
	* YYYY-MM-DD HH:MM+XXYY or YYYY-MM-DD HH:MM:SS+XXYY - both time and timezone offset were specified.		* YYYY-MM-DD HH:MM+XXYY or YYYY-MM-DD HH:MM:SS+XXYY - both time and timezone offset were specified.

			==== Date and time parsing issues ====
			* 2026-02-03: What should a parser do if the value is not “overall valid”?
			** Raised by jkingweb in chat: https://chat.indieweb.org/microformats/2026-02-03#t1770133542875900

	=== format specific details ===		=== format specific details ===

Tantek: editorial: keep discouragement of colons in published tz offsets

2022-06-25T03:04:28Z

editorial: keep discouragement of colons in published tz offsets

← Older revision		Revision as of 03:04, 25 June 2022
Line 181:		Line 181:
	** Z is the literal 'Z' to indicate GMT.		** Z is the literal 'Z' to indicate GMT.
	** For the purposes of the value class pattern, the colons ":" separating the hour, minutes, seconds are required.		** For the purposes of the value class pattern, the colons ":" separating the hour, minutes, seconds are required.
	** However the colons ":" separating the hours and minutes of any timezone offset are ''optional''. If the offset uses XX:YY format, remove the colon so it is XXYY format. ~~This~~ makes it less likely that a timezone offset will be confused for a time.		** However the colons ":" separating the hours and minutes of any timezone offset are optional and discouraged. If the offset uses XX:YY format, remove the colon so it is XXYY format. Omitting the colon makes it less likely that a timezone offset will be confused for a time.
	** Case insensitive { }"am"\|{ }"a.m." suffix to treat an HH value of 12 as 00, or a case-insensitive { }"pm"\|{ }"p.m." suffix to add 12 to HH value less than 12 - per [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia article on the 12 hour clock]. Note: [[X2V]] has implemented this.		** Case insensitive { }"am"\|{ }"a.m." suffix to treat an HH value of 12 as 00, or a case-insensitive { }"pm"\|{ }"p.m." suffix to add 12 to HH value less than 12 - per [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia article on the 12 hour clock]. Note: [[X2V]] has implemented this.
	*** HH:MM:SSam		*** HH:MM:SSam

GRegorLove: /* Date and time parsing */ resolved vcp: normalize timezone offset https://github.com/microformats/microformats2-parsing/issues/56

2022-06-24T21:40:03Z

Date and time parsing: resolved vcp: normalize timezone offset https://github.com/microformats/microformats2-parsing/issues/56

← Older revision		Revision as of 21:40, 24 June 2022
Line 181:		Line 181:
	** Z is the literal 'Z' to indicate GMT.		** Z is the literal 'Z' to indicate GMT.
	** For the purposes of the value class pattern, the colons ":" separating the hour, minutes, seconds are required.		** For the purposes of the value class pattern, the colons ":" separating the hour, minutes, seconds are required.
	** However the colons ":" separating the hours and minutes of any timezone offset are ''optional'' ~~and discouraged in order to make~~ it less likely that a timezone offset will be confused for a time.		** However the colons ":" separating the hours and minutes of any timezone offset are ''optional''. If the offset uses XX:YY format, remove the colon so it is XXYY format. This makes it less likely that a timezone offset will be confused for a time.
	** Case insensitive { }"am"\|{ }"a.m." suffix to treat an HH value of 12 as 00, or a case-insensitive { }"pm"\|{ }"p.m." suffix to add 12 to HH value less than 12 - per [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia article on the 12 hour clock]. Note: [[X2V]] has implemented this.		** Case insensitive { }"am"\|{ }"a.m." suffix to treat an HH value of 12 as 00, or a case-insensitive { }"pm"\|{ }"p.m." suffix to add 12 to HH value less than 12 - per [http://en.wikipedia.org/wiki/12-hour_clock Wikipedia article on the 12 hour clock]. Note: [[X2V]] has implemented this.
	*** HH:MM:SSam		*** HH:MM:SSam

Tantek: update summary: vcp is a standard by way of inclusion in microformats2-parsing, tests, and interoperable implementations, explicitly note introduction status examples sections as informative, status in use by mf2

2022-06-22T22:36:12Z

update summary: vcp is a standard by way of inclusion in microformats2-parsing, tests, and interoperable implementations, explicitly note introduction status examples sections as informative, status in use by mf2

← Older revision		Revision as of 22:36, 22 June 2022
Line 1:		Line 1:
	{{DISPLAYTITLE:Value Class Pattern}}		{{DISPLAYTITLE:Value Class Pattern}}

	The '''<dfn>value class pattern</dfn>''' is a set of ~~ways~~ to markup the value of a microformats property in part of an element, a title attribute, or across multiple elements.		The '''<dfn>value class pattern</dfn>''' is a standard set of techniques to markup the value of a microformats property in part of an element, a title attribute, or across multiple elements, and how to parse & normalize those markup techniques.

	; Editors		; Editors
Line 8:		Line 8:
	; Short URL		; Short URL
	: <kbd>http://ufs.cc/w/vcp</kbd>		: <kbd>http://ufs.cc/w/vcp</kbd>

			== Introduction ==
			This section is '''informative'''.

	Use the value class pattern when you need to markup:		Use the value class pattern when you need to markup:
Line 17:		Line 20:

	==Status==		==Status==
	The value-class-pattern is feature complete, ready for use in markup, and supported in implementations such as [[search engines]], [[parsers]], and Firefox [[Operator]]. [[H2VX]] supports date and time separation but not value-title. See also the [http://microformats.org/blog/2009/05/12/value-class-pattern/ blog announcement].		This section is '''informative'''.

			The value-class-pattern is feature complete, ready for use in markup, and supported in implementations such as [[search engines]], [[parsers]], and Firefox [[Operator]]. [[H2VX]] supports parsing date and time separation but not value-title. See also the [http://microformats.org/blog/2009/05/12/value-class-pattern/ blog announcement].

			The [[microformats2-parsing]] specification normatively references the value-class-pattern, and [[microformats2]] parsers implement it.

	==Simple Examples==		==Simple Examples==
			This section is '''informative'''.

	Here is markup for a home phone number:		Here is markup for a home phone number:

Tantek: editorial: add explicit 'informative' declarations to a couple more sections which weren't specifying any features

2022-06-22T22:29:39Z

editorial: add explicit 'informative' declarations to a couple more sections which weren't specifying any features

← Older revision		Revision as of 22:29, 22 June 2022
Line 556:		Line 556:

	== Background ==		== Background ==
			This section is '''informative'''.

	The value class pattern is derived from [[hCard#Value_excerpting\|value-excerpting]] in hCard.		The value class pattern is derived from [[hCard#Value_excerpting\|value-excerpting]] in hCard.

Line 587:		Line 589:

	== Translations ==		== Translations ==
			This section is '''informative'''.

	Read the value-class-pattern specification in additional <span id="languages">languages</span>:		Read the value-class-pattern specification in additional <span id="languages">languages</span>:
	* [[value-class-pattern-fr\|français]]		* [[value-class-pattern-fr\|français]]

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:33:48Z

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

← Older revision		Revision as of 16:33, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~Value Class Pattern~~</entry-title>~~		{{DISPLAYTITLE:Value Class Pattern}}

	The '''<dfn>value class pattern</dfn>''' is a set of ways to markup the value of a microformats property in part of an element, a title attribute, or across multiple elements.		The '''<dfn>value class pattern</dfn>''' is a set of ways to markup the value of a microformats property in part of an element, a title attribute, or across multiple elements.

Tantek: link proposed to issue to comment / provide feedback on #27

2018-03-25T21:23:22Z

link proposed to issue to comment / provide feedback on #27

← Older revision		Revision as of 21:23, 25 March 2018
Line 198:		Line 198:
	** ignore any further "value" elements that specify the timezone.		** ignore any further "value" elements that specify the timezone.

	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 by concatenating the specific date (PROPOSED: normalized to YYYY-MM-DD), " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).		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 by concatenating the specific date ([https://github.com/microformats/microformats2-parsing/issues/27#issuecomment-376004491 PROPOSED]: normalized to YYYY-MM-DD), " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).
	* YYYY-MM-DD - no time specified		* YYYY-MM-DD - no time specified
	* YYYY-MM-DD HH:MM or YYYY-MM-DD HH:MM:SS - time specified but no timezone. This is a floating time.		* YYYY-MM-DD HH:MM or YYYY-MM-DD HH:MM:SS - time specified but no timezone. This is a floating time.

Tantek: assembled dates must be normalized YYYY-MM-DD (because parsed output consuming code likely expects that, either way, simpler for JSON consuming code), proposed since parsers disagree

2018-03-25T21:17:44Z

assembled dates must be normalized YYYY-MM-DD (because parsed output consuming code likely expects that, either way, simpler for JSON consuming code), proposed since parsers disagree

← Older revision		Revision as of 21:17, 25 March 2018
Line 198:		Line 198:
	** ignore any further "value" elements that specify the timezone.		** ignore any further "value" elements that specify the timezone.

	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 by concatenating the specific date, " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).		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 by concatenating the specific date (PROPOSED: normalized to YYYY-MM-DD), " " (space character) and specific time (if time was specified, with 00 minutes implied if no minutes are provided), and specific timezone (if timezone and a specific time was specified).
	* YYYY-MM-DD - no time specified		* YYYY-MM-DD - no time specified
	* YYYY-MM-DD HH:MM or YYYY-MM-DD HH:MM:SS - time specified but no timezone. This is a floating time.		* YYYY-MM-DD HH:MM or YYYY-MM-DD HH:MM:SS - time specified but no timezone. This is a floating time.

Tantek: /* microformats2 parsers */ better subhead

2017-07-21T19:17:50Z

microformats2 parsers: better subhead

← Older revision		Revision as of 19:17, 21 July 2017
Line 341:		Line 341:
	** imply 00 seconds if seconds are omitted due to Atom artificial precision syntax requirements		** imply 00 seconds if seconds are omitted due to Atom artificial precision syntax requirements

	==== microformats2 parsers ====		==== microformats2 parsers implied date ====
	Since microformats2 parsers are generic, instead of checking for specific properties (as above for hAtom and hCalendar), they must perform the following algorithm to imply dates for dt-* properties:		Since <span id="microformats2 parsers">[[microformats2#parsers\|microformats2 parsers]]</span> are generic, instead of checking for specific properties (as above for hAtom and hCalendar), they must perform the following algorithm to imply dates for dt-* properties:

	* if a dt-* property has a time but lacks a date		* if a dt-* property has a time but lacks a date

Tantek: /* microformats2 parsers */ remove "proposal" text, this was resolved with http://microformats.org/wiki/microformats2-parsing-issues#implied_date_for_dt_properties_both_mf2_and_backcompat

2016-07-14T14:58:02Z

microformats2 parsers: remove "proposal" text, this was resolved with http://microformats.org/wiki/microformats2-parsing-issues#implied_date_for_dt_properties_both_mf2_and_backcompat

← Older revision		Revision as of 14:58, 14 July 2016
Line 342:		Line 342:

	==== microformats2 parsers ====		==== microformats2 parsers ====
	~~Proposal 2012-283:~~		Since microformats2 parsers are generic, instead of checking for specific properties (as above for hAtom and hCalendar), they must perform the following algorithm to imply dates for dt-* properties:

	Since microformats2 parsers are generic, instead of checking for specific properties (as above for hAtom and hCalendar), they ~~may~~ perform the following algorithm to imply dates for dt-* properties:

	* if a dt-* property has a time but lacks a date		* if a dt-* property has a time but lacks a date
Line 352:		Line 350:
	** otherwise it simply has a time (and no date).		** otherwise it simply has a time (and no date).

	This ~~should result~~ in a similar enough implementation/interpretation as the previous vocabulary dependent heuristics for hAtom and hCalendar that a microformats2 parser ~~could~~ produce similar results for h-entry and h-event without having to know about their specific dt-* properties.		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.

	=== derivation and tests ===		=== derivation and tests ===