- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 19 Mar 2009 01:35:45 +0000 (UTC)
Over the past month or so I have collected about 142 e-mails on the topic
of the <time> element and other time-related subjects. This is an attempt
to address that feedback.
I have attempted below to reply to all the substantial feedback in these
threads. I have intentionally ignored e-mails and parts of e-mails that
repeated points made in earlier e-mails, that made claims from authority,
and e-mails that did not start from the basis of use cases, demonstrated
needs, and logical argumentation. I have also ignored proposals that were
explicitly put forward with the caveat that they did not fix problems that
we need to fix. If you feel I have missed a point that should affect the
specification, please let me know.
Also, a reminder: please do not cross-post e-mails to both the WHATWG list
and the public-html list. Since the WHATWG list bounces e-mails from
non-subscribers, cross-posting will lead to the thread being fragmented,
with some people only seeing some parts of the discussion. Please feel
free to pick one list or the other when commenting on HTML5, but avoid
cross-posting. Thanks!
On Mon, 23 Feb 2009, Andy Mabbett wrote:
>
> The HTML5 time element has the potential to resolve [the accessibility
> problems caused by abusing the <abbr> element for things like
> machine-readable dates], but only if it caters for all the cases in
> which microformats are -- or could potentially be -- used.
I don't agree with the conditional there. We can improve matters even if
we only address a small number of cases relative to the total number of
potential uses.
In particular, HTML5 is explicitly being designed with the goal of only
attempting to address common use cases, leaving the rarely-relevant cases
unaddressed. We call this the 80/20 rule: Only 80% of use cases (by usage)
are addressed, leaving the remaining 20% for future versions.
> hCalendar microformats are already used to mark up imprecise dates
> ("June 1977"; "2009"). ISO8601 already supports them. Why not HTML5?
HTML5 does support them. Here is how you can write June 1977 in HTML:
<p>I was married in June 1977.</p>
Here is how you can refer to a year:
<p>The operating system was released in 2009.</p>
The primary use cases for <time> are:
* The ability to encode 80% of dates and times in a machine-readable way
so that the user can make use of them in an automated fashion, in
particular for adding dates to a calendar.
* The ability to restyle dates that contain a "day" component so that
they follow user conventions (2000-12-31 vs 31-12-2000 vs 12-31-2000).
* The ability to encode the output of <input type=date> and <input
type=time> in an unambiguous fashion, for styling.
None of these require that <time> be able to express years or year-month
pairs; what are the use cases that we should address that need <time> to
support these formats?
> [non-Gregorian dates]
> [dates before 1CE]
It isn't clear that either of these are needed to address the above use
cases either.
> Another abuse of ABBR in microformats for coordinates:
>
> <abbr class="geo" title="52.548;-1.932">Great Barr</abbr>
>
> [...] this could be resolved, and HTML5 usefully extended, by a
> "location" element:
>
> <location latitude="52.548" longitude="-1.932">Great
> Barr</location>
It isn't clear what use case this addresses. Is this for use with mapping
applications? Wouldn't a new protocol be a better way of addressing this,
e.g.:
<a href="latlong:52.548;-1.932">Great Barr</a>
...where applications like Google Earth could register for latlong:?
> Now all we need to do is to work-around the abuse of ABBR for durations,
> in the draft hAudio microformat:
>
> <abbr title="PT3M23S">3 minutes 23 seconds</abbr>
Surely that should be:
<abbr title="3 minutes 23 seconds">PT3M23S</abbr>
Anyway, I expect that whatever solution we come up with for RDFa will
address this particular issue.
On Tue, 24 Feb 2009, Andy Mabbett wrote:
> Lachy wrote:
> >
> > Why would most people need to mark up lunar co-ordinates?
>
> For example: to allow such points to be easily found on maps, or in
> tools like Google Earth - the same as can be done presently for
> terrestrial coordinates, using "Geo" microformats.
Most people don't do that. This doesn't even remotely make the "80%" cut.
> More seriously, a more widely-scoped "measurement" element, capable of
> taking, for example, values of "duration", "length", "mass",
> "temperature", etc.; and a value; and perhaps a schema (defaulting to
> SI), would perhaps be more useful. Use cases are microformats, plus
> translation, automated conversion, sorting, etc.
I encourage you to read our FAQ, in particular the part on how to propose
features:
http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_the_spec.3F
We would need use cases that are much more concrete than "automated
conversion, sorting, etc". Showing existing non-demo software that works
around the problem (e.g. using a microformat) is a good way to demonstrate
a use case.
On Tue, 24 Feb 2009, Andy Mabbett wrote:
>
> What's the expected end-of-life date for HTML5? Do we really want to
> hamstring ourselves 'til then, by considering only current, as-of-2009,
> capabilities?
New features will be added -- either to HTML5, or HTML6, or later -- as
and when they are needed. We don't hamstring ourselves by not adding them
today.
On Wed, 4 Mar 2009, Matthew Somerville wrote:
>
> What if you only know someone's birthdate accuracy to the month? I know
> someone whose grandma was born in October 1911, but they're not sure of
> the precise day. Can they mark up their grandad because they know on
> which date he was born, but not their grandma?
Why would they need to mark up they date, if they don't know it exactly?
Surely this is fine:
<p>Dad was born on <time>1911-01-01</time>.</p>
<p>Mum was born sometime in February 1911.</p>
What use case does this not address?
> Being able to have "1911-10-00" (or whatever) would still mean I could
> locate all relatives born in 1911 using such a <time> element.
HTML isn't a database format. If you want to do things like locate
relatives, HTML isn't going to help you. Use GEDCOM or some such system.
> I currently have a database of thousands of 1960s pop concerts, for
> which I'd quite like to use HTML5 when putting online some time soon
> (not having it online yet to show you probably ruins my case, but this
> is an adapted true story). Now, the people who went to those concerts
> quite often had slightly hazy memories - I coudn't possibly think why!
> ;) - and can't remember precisely the day the concert took place, but
> they know it was in May 1967. My database is currently storing that
> concert date as 1967-05-00 and I can't see the logic in only being able
> to mark up the datetime elements that happen to have a day of the month
> attached. For anyone trying to use <time> programatically, it'll be more
> confusing that they won't get all the results for May 1967, so I'd
> probably be better off not using <time> at all.
I don't see how the <time> element has anything to do with this. Surely
when you search a database, you would look at the actual database, not the
HTML files.
On Wed, 4 Mar 2009, Jim O'Donnell wrote:
>
> [...] one of the sites I look after is the National Maritime Museum
> archive search, which includes ~70,000 records dating from the 16th
> century to present. Of those, around 3,500 predate the Gregorian
> calendar and have, presumably, Julian dates: http://is.gd/lFrh
>
> It would be useful to mark up these dates as dates in the HTML versions
> of the catalogue records.
Why? How would marking these dates up be useful? Surely any data mining on
this data would use the original records, not an HTML representation.
On Thu, 5 Mar 2009, jim at eatyourgreens.org.uk wrote:
>
> Is <time> then like <address> in HTML 4? ie. intended for certain dates
> only, just as <address> may not be used to mark up all addresses? In
> that case, the spec should be clear on correct and incorrect usage, with
> examples of both to guide authors.
It can be used (thought might not always be particularly useful) for any
date in the proleptic Gregorian calendar from 1AD onwards. The spec has a
number of examples; could you elaborate on what you would like to see
added? I have added a couple; are they enough?
> Bruce Lawson uses <time> to mark up the dates of blog posts in the HTML5
> version of his wordpress templates. Is this incorrect usage of HTML5? If
> not, how should HTML5 blog templates work when the blog is dated from
> 1665 (http://pepysdiary.com) or 1894 (http://www.cosmicdiary1894.blogspot.com/)?
1894 would work fine; 1665 would require careful conversion from the
Julian calendar. A blog supposedly from 100BCE couldn't be marked up.
In practice these are edge cases. We're not trying to solve every problem;
you'll always be able to find problems that aren't addressed. ("How do I
mark up the time of a blog for someone writing on a space ship going at
0.9c but publishing on a server in my reference frame?")
On Thu, 5 Mar 2009, Philip Taylor wrote:
>
> In any situation where they use <time>, they'd probably want to write
> something like:
>
> print "<time datetime=".$t->toISO8601Date().">".$t->toLocalisedHumanReadableDate()."</time>";
>
> But given HTML5's restrictions against BCE years, they'd actually have
> to write something more like:
>
> if ($t->getYear() > 0) { # (be careful not to write ">= 0" here)
> print "<time class=time
> datetime=".$t->toISO8601Date().">".$t->toLocalisedHumanReadableDate()."</time>";
> } else {
> print "<span class=time>".$t->toLocalisedHumanReadableDate()."</span>";
> }
>
> and make sure their stylesheets use the selector ".time" instead of
> "time", to guarantee everything is going to work correctly even with
> unexpected input values.
>
> So the restriction adds complexity (and bugs) to code that wants to be
> good and careful and generate valid markup.
That rather depends on the data type that $t uses. Regardless of what we
allow, there will always be date/time data types that can't be expressed.
For example, if the data type allows minutes to be marked as unknown, an
we require hour-minute times. Similarly, if we allow arbitrary years, then
we might underflow the underlying data type. Allowing 1..Inf keeps the
syntax simple.
Note that not allowing any dates before the 1700s is pretty silly, because
the calendar existed before then, and allowing dates before the 1500s is
pretty silly also, since it didn't exist before then. Converting to and
from contemporary dates to Gregorian is not at all obvious. The only
reason the spec doesn't disallow dates before the Gregorian calendar is
that the Gregorian calendar started at different times in different
countries, and just allowing anything from 1 seemed easier than trying to
find a minimum value and defining a reference country for interpreting
dates around then, etc.
On Thu, 5 Mar 2009, Jim O'Donnell wrote:
>
> I would say a key use case for marking up historic dates is searching
> large archives by date eg. searching the National Maritime Museum
> archive for Elizabethan Navy records dating from 1595.
Why wouldn't just searching for "1595", with no markup involved, be good
enough for this?
On Thu, 5 Mar 2009, Bruce Lawson wrote:
>
> And if there is a limit on a use case, it should be in the spec. There
> is nothing I can see in the editors draft that limits the use of <time>.
> (I use it on my website to markup publication dates of blog entries and
> comments; why on earth wouldn't I?)
The use cases are why the feature is there, they're not a limit on people
using it.
> What it does limit is the format: no "fuzzy dates" like "July 1897" for
> my great grandmother's birthday (no-one remembers the exact day) or the
> precise date of Charlemagne death "28 January 814"
The latter can be given, if you convert from Julian to Gregorian.
0814-01-28 is probably not the right date; you'd probably want 0814-02-01
if I'm doing my maths right. The problem is that this is confusing, and
people aren't going to know. If you tell someone "January 28 814" they
don't think you mean February. If someone encodes that date using <time>,
they'll almost certainly get it wrong.
Allowing dates before Gregorian is bad enough, but if we go back even
further we're just asking for trouble.
On Thu, 5 Mar 2009, jim at eatyourgreens.org.uk wrote:
>
> I think limiting the HTML5 spec based on the capabilities of user-agents
> (or client software) is dangerous. Firstly, software capabilities change
> over time as features are added/removed. Secondly, capabilities vary
> between languages and applications. To add to Philip's examples, mysql
> datetimes are restricted to years >= 1000 while MS Sql Server will not
> accept datetimes prior to 1752. Hence developers parse dates into their
> components and use integer types, not datetimes, for very old stuff.
> Should HTML5 cater to the lowest common denominator and refuse datetimes
> before 1752?
Why 1752? France adopted it in 1582, most of Switzerland in 1583.
If we assuming we're doing this by Great Britain's reckoning, and we
switch in 1752, do we allow dates before September 14th?
> However, Henri is also right that a limited datetime in HTML needs to be
> absolutely clear in the spec too, which it isn't at the moment.
I've tried to clarify it. Please let me know if the spec is still too
vague.
On Mon, 9 Mar 2009, Bruce Lawson wrote:
>
> Here are some (randomly selected) examples of microformats that are
> already being used to mark up historical dates in wikipedia, of the kind
> that would be illegal for 2 reasons; firstly, because they are not in
> the future, and also because they aren't precise (eg full YYYY-MM-DD
> format) or are ancient.
Note that past dates are allowed, the cut off is 1AD Gregorian.
> http://en.wikipedia.org/wiki/Public_Worship_Regulation_Act_1874
> http://en.wikipedia.org/wiki/Septennial_Act_1715
> http://en.wikipedia.org/wiki/George_Washington_Carver
> http://en.wikipedia.org/wiki/John_Everett_Millais (birth date in hCard)
> 1066 has one hCalendar, with: <SPAN class="summary dtstart">1066</SPAN> :
> http://en.wikipedia.org/wiki/1066
What is the use of any of those? And what calendar do they use? Are they
really Gregorian dates?
> I suggest that the short list of apps that consume microformatted
> historical data should not be used to indicate that it's not a
> worthwhile use case.
The question isn't really whether it's worthwhile or not, but whether it's
important enough to deal with today rather than later.
> After all, I know of no user agents that can use time, section, footer,
> datagrid etc but we mostly expect there to be soon.
I don't. Most of the new elements are just meant to make styling easier,
so that we don't have to use classes.
On Mon, 9 Mar 2009 sean at elementary-group-standards.com wrote:
>
> I took the values used in the Datetime Examples 2.4.4 Dates and times, 2.4.4.5 Global dates and times,
>
> "0037-12-13T00:00Z"
> "1979-10-14T12:00:00.001-04:00"
> "8592-01-01T02:09+02:09"
>
> My test: http://www.elementary-group-standards.com/index.php?id=420
> Validation results: http://validator.w3.org/check?uri=http%3A%2F%2Fwww.elementary-group-standards.com%2Findex.php%3Fid%3D420 which offer
>
> [ins datetime="0037-12-13T00:00Z">"[code>0037-12-13T00:00Z[/code>"[/ins>
> Bad value 0037-12-13T00:00Z for attribute datetime on element ins: The literal did not satisfy the date format.
> Syntax of datetime with timezone:
> (This format deviates from the spec draft.) An ISO 8601 date and time with a time zone designator, i.e. YYYY-MM-DDThh:mm:ss optionally followed by . and one or more digits for the fraction of a second, and finally
> followed by either Z, +hh:mm or -hh:mm. Examples: 1996-01-01T12:05:25Z, 1996-01-01T12:05:25.6+02:00.
>
> [ins datetime="8592-01-01T02:09+02:09">"[code>8592-01-01T02:09+02:09[/code>"[/ins>
> Bad value 8592-01-01T02:09+02:09 for attribute datetime on element ins: The literal did not satisfy the date format.
> Syntax of datetime with timezone:
> (This format deviates from the spec draft.) An ISO 8601 date and time with a time zone designator, i.e. YYYY-MM-DDThh:mm:ss optionally followed by . and one or more digits for the fraction of a second, and finally
> followed by either Z, +hh:mm or -hh:mm. Examples: 1996-01-01T12:05:25Z, 1996-01-01T12:05:25.6+02:00.
>
> Either the dates are good per the examples or the dates are bad as per validation or, the Specification's text needs to be clearer regarding use.
This appears to be a bug in the validator. All three dates seem to be
valid per spec.
On Mon, 9 Mar 2009, Tom Duhamel wrote:
>
> My opinion is that all the following dates are precise:
> 2009
> 2009-03
> 2009-03-09
Would you need to mark up the first two using a <time> element?
> There are numerous reason to use dates which are not very precise, but
> are still precise nevertheless. I'm going to release the new version of
> my current project in <time datetime="2009-04">April</time> but I cannot
> tell as of now the exact day of the release.
Why do you need the <time> element at all here?
> From my understanding of the current draft, the earlier date that can be
> used is 1970-01-01. The Unix epoch. Why that limit?
You can use any date in the Gregorian calendar, as well as any date up to
1AD in the proleptic Gregorian calendar. I'm not sure where you saw a 1970
limit; could you point to that part of the spec so it can be fixed?
On Tue, 10 Mar 2009, Andy Mabbett wrote:
>
> If I wish to compare my earnings, or the average daily rainfall, or
> somesuch, for 2007 and 2008, then the four-figure "yyyy" value is as
> precise as it is possible to be; anything with higher granularity would
> introduce bogus precision.
I agree, but if you're doing that, you shouldn't be using HTML.
Comparisons like that is what spreadsheets are for.
On Tue, 10 Mar 2009, Toby A Inkster wrote:
>
> It does seem to me to be a little foolhardy for HTML5 to be defining its
> own format for representing dates and times. ISO 8601 is already widely
> understood and implemented. Out of the box it is capable of representing
> any instant[1] between 10000 BC and 9999 AD, including leap seconds and
> any other edge case you choose to think about. Why reinvent the wheel?
HTML5 uses a subset of ISO8601.
On Tue, 10 Mar 2009, Charles McCathieNevile wrote:
>
> Enabling these more complex use cases would resolve a lot of people's
> uneasiness over the limited utility of the current design.
It would also introduce a lot of uneasieness about the spec being too
large and attempting to be too many things for too many people. :-)
> It would also make it easier to explain to communities who publish or
> hold large amounts of metadata how HTML 5 gives them a clear benefit. An
> alternative approach of course would be to enable RDFa, since using RDF
> it is already simple to deal with these use cases, and the people who
> have them very often ahve their data in an RDF-compatible form already.
I think that it would make sense to examine these use cases in the context
of RDFa rather than just in the context of <time>, yes.
On Mon, 16 Mar 2009, Leif Halvard Silli wrote:
>
> Proposal: Specify that, just as @title in the <abbr> element has a specific
> purpose, @title in <time> has the specific purpose of containing the bespoken
> time in an format and calendar relevant to the text.
I don't understand what you mean here.
On Wed, 11 Mar 2009, David Singer wrote:
>
> I wonder why the 'try to parse the content' step is in there?
It's so that you can do:
<time>2008-01-01</time>
...instead of:
<time datetime="2008-01-01">2008-01-01</time>
On Wed, 11 Mar 2009, Leif Halvard Silli wrote:
>
> The current draft text says that <time> "represents a precise date
> and/or a time in the proleptic Gregorian calendar".
>
> This gives the impression that one cannot use <time> for such things as
> David mentioned. If it is meant that one should be able to use <time>
> for giving the date of the October revolution ...
>
> <p><time datetime="1917-11-7">25 October 1917</time>
> <p><time>25 October 1917</time>
>
> ... then the draft text should be changed to stress that it is the
> *datetime* attribute which "represents a precise date and/or a time in
> the proleptic Gregorian calendar".
The element represents the time given by the attribute or, if there is no
attribute, its contents. Could you elaborate on how that is wrong? I don't
understand.
On Thu, 12 Mar 2009, Bruce Lawson wrote:
>
> Real problems to be solved:
>
> 1) microformats have accessibility problems with <abbr>; time element
> solves that - but if the only "valid" use is to mark up future events
> (as Henri suggests), then pages become "invalid" as they age. (Much like
> me, actually)
The spec overrides Henri here. :-) And the spec allows all Gregorian dates
(and a number of non-Gregorian dates, since it is based on the proleptic
Gregorian calendar).
> 2) microformats are already used "in the wild" to mark up past events.
> sometimes ancient and sometimes without DDMMYYYY precision. People who
> wish to do that won't be able to use <time>, so it perpetuates the
> accessibility problems it wishes to solve and fragments the way dates
> are marked up on the Web; some will use time, some will use microformats
It's unclear what the "real problem" is here that leads to these authors
using any markup for these at all.
> What advantage is there for authors and consumers by *not* extending the
> range of dates that can be described with <time> ?
It solves your use #1, which is probably a far more common case than #2.
That seems likely to be enough as a first step.
On Thu, 12 Mar 2009, Charles McCathieNevile wrote:
>
> A big producer of content is the world of libraries and document
> archivists. Example I already gave, such as the British Parliament, are
> maintain collections that they are putting online, of documents whose
> dates go back past the English conversion to the Gregorian calendar two
> and a half years ago. Similarly, while I don't think anyone from the
> Chinese National LIbrary system is on this list (there are drawbacks to
> havinga high-colume english-language list and thinking it might be
> representative) I can tell you that they have a huge number of documents
> that date to before the Chinese conversion to a Gregorian calendar in
> 1949, many that date to before the proleptic Gregorian date 0001-01-01,
> and many whose dating is a range.
>
> They are not alone. Many libraries around the world, and musea, collect
> things, publish information about them, and already have carfeully
> developed metadata stores. These are the kind of institutions who asked
> for the Semantic Web and use it. They also often publish to the public
> some of their high-quality data, with a lot more typically available to
> researchers or people who have otherwise been given acces. (You can find
> this stuff with search engines - it isn't rocket science. A random query
> to ask.com got me to http://www.davidrumsey.com/directory/ which uses
> all kinds of dates, including pre-Gregorian and ranges. I believe that
> this isn't just one edge case, but I am not going to spend the week
> searching the web to prove it).
Agreed, there is lots of non-Gregorian content on the Web. But why would
this content use <time>?
> It has been pointed out that allowing for negative years would not be
> difficult, (in the parsing-rules mold of the spec, it is "if the string
> starts with a hypen, it's negative") would allow for a number of use
> cases such as
> http://www.britishmuseum.org/explore/highlights/highlight_objects/cm/g/gold_stater_in_the_name_of_tit.aspx
> or http://en.wikipedia.org/wiki/List_of_Roman_consuls#First_century_BC
> and so on.
I don't understand. What is the use case here? Why does the current markup
not suffice?
> > Another case for an imprecise date might be:
> >
> > <p><time>2009</time> is The International Year of Astronomy.</p>
> >
> > For this, we would need to understand what real benefit consuming
> > applications would gain from that. It's not really a date that
> > someone would want to import directly into their calendar.
>
> Why on earth not? I have imported such things into calendars before.
> There is a lot of money spent on calendars explaining what chinese year
> we are in, or what holidays and festivals are expected, and some of this
> is "what did the UN or the CWA or the Secret Cabal or the HR department
> declare this year to be?"
Could you show me an example of a workflow in an application today that
triggers based on years? Why can't the use just type in the year if that's
what he wants? I really don't understand how marking up a year is useful.
On Thu, 12 Mar 2009, Tab Atkins Jr. wrote:
>
> Allowing negative years is so trivial on the parsing side as to make it
> somewhat ridiculous that it's not supported.
Exposing Gregorian dates for time before the Gregorian calendar existed
is ridiculous, IMHO; it's allowed only because finding a start date for
the Gregorian calendar is non-trivial and harder than just saying "1".
Introducing negative numbers is non-trivial extra complexity; what does it
get us? What are the actual concrete use cases? Is there software that
does something with documents that would actually want proleptic Gregorian
calendar dates?
It's worth noting Wikipedia's comment on the matter: "this proleptic
calendar should be used with great caution". It's also worth noting that
ISO8601 uses astronomical year numbering which differs from the
traditional proleptic Gregorian calendar and the Julian calendar. Thus,
March 3rd 1BC (Julian) would be 0000-03-01 in ISO8601 (two days "earlier"
and in a different year!). The chances of authors actually getting this
kind of thing right are so remote that I really don't see any value in
actually allowing it. There's no point having machine-readable dates if
all the dates are wrong.
> Supporting ranges seems to have a strong case for inclusion based on the
> current dates. As Charles says, it's relatively common for current
> calendar events to take place over more than one day. Making time apply
> only to single days renders us incapable of marking this up in a
> machine-readable way, which means that many common, current, real-world
> events can't be automagically imported into a calendar app
> appropriately.
hCalendar seems to handle this fine with <time> (as per the example in the
spec). Wouldn't that be the preferred way of important an event?
On Thu, 12 Mar 2009, Leif Halvard Silli wrote:
>
> If the focus is on exposing ambiguous dates, then what is the purpose of
> limiting it to proleptic Gregorian dates? For example the battle of
> Hastings (16th of October 1066 - according to the Julian calendar [1]).
> It would only be confusing to expose that date to some users - e.g. to
> AT users - in the proleptic Gregorian date format.
Indeed, using <time> for this use cases seems unnecessary.
> If the purpose is exposing ambiguous dates, it would also not hurt
> anyone in need of unambiguous date information, to simply ignore the
> fact that @datetime - as drafted - is supposed to contain proleptic
> Gregorian dates. Simply using <time datetime="1066-10-16">October
> 16th</time> would bring the expected user experience.
Wouldn't
<p>... October 16th ...</p>
...bring about exactly the same user experience?
On Sat, 14 Mar 2009, Smylers wrote:
>
> So my suggestion for a spec change is to replace "zero" with "1582".
> That further reduces the set of dates that <time> can represent, but
> avoids the complexity of pre-Gregorian dates, and avoids inadvertently
> giving a meaning to them that hampers the efforts of a future version of
> HTML to do all of this right.
It doesn't avoid the complexity of pre-Gregorian dates, sadly. Greece only
started using the Gregorian calendar in 1923, so there are probably still
people alive who, if they mark up their date naively using <time>, will
end up encoding it wrongly (i.e. as a proleptic Gregorian date that
doesn't match the actual date they were born on). So if we are to avoid
dates that could be confused with non-Gregorian dates, we should use
disallow dates before 1 March 1923. But that's not really practical, since
there are many people who will want to mark up dates from the 19th and
early 20th century and who have really no reason not to do so, since the
calendar was adopted in their country long before 1923.
This is why I just went with 1AD as the first allowed year.
On Sat, 14 Mar 2009, Tom Duhamel wrote:
>
> Use ISO 8601 with the following provisions:
> - Allow all four digit years, positive and negative
Negative dates (especially ISO8601 negative dates) would almost certainly
be used incorrectly, as noted above. Furthermore, there doesn't really
seem to be a real use for marking up historical dates this far back. (If
we don't follow ISO8601 here, and skip from 1 to -1, then I think we will
have even more confusion. So that doesn't help.)
> - Allow lower granularity dates: 2009-03-14, 2009-03, 2009
It's not clear what benefit we get from marking up months and years
without days.
> - Allow ranges: 2009-03-01/2009-03-14
This is already possible with two <time> elements, as demonstrated by the
hCalendar example in the spec.
> - Allow only extended format: 2009-03-14 (rather than 20090314) which will
> help with simplification and future extensions
Already in the spec.
On Sun, 15 Mar 2009, Tom Duhamel wrote:
>
> Since I always thought of HTML as a method of enclosing content for the
> purpose of display only, my thinking was that it was not important
> whether or not year 0 existed or not. I thought that an author would put
> -54-03-17 and the user agent would show "March 17th, 54 BC". Then if one
> decides he likes the year 0, he would put 0000-12-25 and the user agent
> would print "December 25th, 0". The browser would just print what we
> told him to print, without an actual understanding of what it means.
This rather defeats the "machine readable" point. :-)
If you want "December 25th, 0", why not just write "December 25th, 0"?
Same with any historical date, for that matter.
On Sun, 15 Mar 2009, Tom Duhamel wrote:
>
> Here is how I would like to see user agents implement the <time> element:
>
> This software was released on <time datetime='2009-02-15'>February 15th,
> 2009</time>.
> This software was released <time datetime='2009-02-15'>just a month
> ago</time>.
> This software was released on <time datetime='2009-02-15'>15/02/09</time>.
>
> In either of these cases, the content is printed on the correct location
> in the sentence. When you hover the mouse, a tool tip pop up with the
> text "February 15th, 2009" or a similar string configured in the user
> agent preferences or the OS preferences. The date might be decorated in
> a way similar to <abbr>.
Per the spec, showing it as a tooltip is allowed, but the primary use for
the attribute is machine-processing, e.g. when converting an hCalendar
block into an iCal blob.
On Tue, 17 Mar 2009, Leif Halvard Silli wrote:
>
> I guess you are satisfied that I agree that <time> should have an
> attribute reserved for ISO time. I would prefer a name that says
> @isotime. And users must be made aware that it is an ISO date.
The attribute is named datetime="" for consistency with other attributes
in HTML with the same syntax (on <ins> and <del> from HTML4).
On Mon, 16 Mar 2009, Tom Duhamel wrote:
>
> It seems that pretty much everyone agrees on this:
> - Allow the use of an alternate calendar, but only Gregorian is required to
> be understood by user agents
You can use any calendar in the contents of the element if you give a
proleptic Gregorian date in the datetime="" attribute.
> - We only require the user agent to display dates; they are free to do more
> if they like (conversion, ...) but are not required to.
The UA is only required to display the contents of the element.
> - Calendar is specified in a new attribute ('calendar' or something similar)
> and the value of 'datetime' attibute is specified in the calendar specified
> by that new attribute
This seems to conflice with the first item above -- why would we allow
calendars to be specified in a machine-readable fashion if browsers only
support the proleptic Gregorian calendar?
> - If 'datetime' attribute is missing, try to interpret the content as an ISO
> date. User agent could print the content as is, or print in a more friendly
> way if desired (in case it was successfully read as a valid ISO date).
This is allowed today. Maybe we should require it? If the datetime
attribute is missing, make it so that the contents must be replaced by a
string that is the locale-dependent rendering of the contents parsed as a
date/time?
> - If content is missing, print 'datetime' attribute (in a friendly way, if
> desired and set by user, or simply as is if unable to do better)
We could do this too, I guess. What do browser vendors think? Is replacing
the contents of <time> with a locale-specific rendering if the element is
empty or the attribute missing something that is acceptable?
> - If both content and datetime are present, print content on page and
> show a representation of the date in datetime with a mechanism such as a
> tool tip
I don't think we need the tooltip in this case, but it is allowed.
On Mon, 16 Mar 2009, Jim O'Donnell wrote:
>
> Can we follow existing practice from TEI ie. datetime may only be
> Gregorian and no other calendar - calendar (if present) identifies the
> calendar in the original text (analogous to the way the HTML lang
> attribute indicates the language of the enclosed text).
If desired, one can use the class="" attribute to annotate the contents of
the element (e.g. to say what calendar it uses).
On Mon, 16 Mar 2009, Smylers wrote:
>
> Suppose I'm a UK user who happens to've configured my computer's date
> format to DD/MM/YYYY (which is common over here) and I see an American
> conference's website American give its date as 04/07/2009. I know that
> the USA date order is different from the UK's, so I'm used to having to
> remember to read that as April 7th. You're suggesting that there should
> be two possibilities I have to take into account:
>
> * The author literally wrote "04/07/2009", and the conference is on April
> 7th.
>
> * The author literally wrote <time>2009-07-04</time>, my browser
> converted that to my local format and displayed it as 04/07/2009, and
> the conference is on July 4th
>
> And that as a reader I can't tell which of these it is, without viewing
> the document's source? (And even to spot that there is an ambiguity
> I've got to be aware that my browser 'sometimes' changes dates, that it
> depends on my computer's configuration, and what config I picked.)
This could indeed be a problem.
> Does the same apply to times? Would they also be converted to the
> user's local timezone?
Pure times wouldn't have a timezone, so no. Same for local date times. For
times with dates and timezones, I guess the UA should just show the
timezone, and possible allow it to be toggled by a click or some such?
This is what implementation experience is good for. :-)
On Tue, 17 Mar 2009, Leif Halvard Silli wrote:
>
> W3C Internationalization allready have a FAQ comment regarding the
> behaviour that Tom proposes here [1]:
>
> "Some have advocated the creation of a <date> tag that would display
> dates according the locale of the user agent. This is subject to the
> same practical issues as described for dynamic date generation with the
> Japanese example. The appropriate format is generally a function of the
> linguistic context of a page, rather than the user's platform."
>
> The "Japanese example" (which discusses using HTTP accept-language
> negotiation):
>
> "* A Japanese person reading the generated date 03/04/02 in an English
> document might mistakenly assume that this used an English ordering. *
> Displaying a generated date in a Japanese date format such as
> ????????? in an English page would probably look out
> of place."
>
> Thus, in a way, such a proposal works against the advice to insert dates
> using ISO. I don't think we want it. (It looks funnily enough when e.g.
> an English Web site suddenly displays parts of the pages in Norwegian
> only because content negotations works "too well".
>
> [1] http://www.w3.org/International/questions/qa-date-format#bytheway
This makes sense; I guess we should not do anything "clever" here (at
least not without author CSS triggering it).
On Mon, 16 Mar 2009, Tom Duhamel wrote:
>
> Assuming that I always saw the name exactly as "Mayan Long Count
> calendar" I guess the correct format would be:
> <time calendar="Mayan Long Count" datetime="12-12-12-12-12">
> which would show correctly "12-12-12-12-12 (Mayan Long Count)" in the
> tooltip.
It's not clear to me what this gains us that can't be done today with
<span> and title="".
On Mon, 16 Mar 2009, Kristof Zelechovski wrote:
>
> Assuming that Gregorian dates are displayed in a tool tip, what happens
> when the user hovers over a time element that has both @datetime and
> @title specified?
This would be up to the user agent.
On Mon, 16 Mar 2009, Mikko Rantalainen wrote:
>
> How about specifying that the content of <time> element will be parsed
> for the date only if 'datetime' attribute is empty.
The spec says this, except s/empty/missing/.
> In addition, the spec should explicitly say that if the content is time
> in any other calendar system but Proleptic Gregorian calendar then the
> datetime MUST contain equivalent time in standard format (whatever the
> spec for 'datetime' will be).
Done.
On Mon, 16 Mar 2009, Kristof Zelechovski wrote:
>
> Note that the specification does not (and cannot) say that a HTML
> document MUST be valid. It merely describes how the user agent should
> handle HTML documents, including ones containing random text.
Actually the spec does say that documents must be valid. That's what it
means to define "valid". By definition, things that are not valid are
wrong, and thus must not be done.
On Mon, 16 Mar 2009, Mikko Rantalainen wrote:
>
> The objective, if I've understood correctly, is to be able to markup a
> specific time. Proleptic Gregorian calendar is suitable for specifying a
> moment of time before 1582 without a doubt.
For experts, sure, but most people aren't going to get it right. Most
people don't know that the calendar changed subtly in the past few
centuries.
On Mon, 16 Mar 2009, Robert J Burns wrote:
>
> So by forcing all dates into a converted Gregorian form, we are forcing
> authors to lose data when they encode a date in HTML.
Why would we force authors to encode the dates in HTML at all? I really
don't understand why anyone would use <time> for such dates.
On Fri, 13 Mar 2009, David Carlisle wrote:
>
> But I was suggesting that if html does decide to leave some things
> undefined, then the xpath operators spec might be a good model (eg
> allowing all positive dates not just those from 15whatever.
HTML5 right now allows years from 1 to Infinity, which seems to be in line
with what you are saying.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 18 March 2009 18:35:45 UTC