[whatwg] <time> (apparantly o)

[I left Robert's replies in, even those I didn't have anything to reply to,
because Robert originally sent the message only to me (off-list).]

On Sun, Mar 15, 2009 at 4:36 PM, Robert J Burns <rob at robburns.com> wrote:

>
> - Allow only extended format: 2009-03-14 (rather than 20090314) which will
>>> help with simplification and future extensions
>>>
>>
>> This may be more controversial. I think we could allow the omission of
>> hyphens for years of four digits. Others have contended that we might also
>> allow the omission of hyphens always if we omit support for ordinal dates
>> (e.g., YYYY-DDD).
>
>
> I don't see a use case for YYYY-DDD, and haven't seen anyone propose one
> yet. I really believe that would be of no use for us. However, see my
> comment below about why I think extended format should be mandatory.
>
>
> Neither do I really. I was simply raising the issue because someone else
> said they wanted hyphens to be optional (I don't recall which message or who
> composed it at the moment).
>

>
> Again I do not claim any expertise here, but I was always told astronomers
> use the year 0 because it makes calculations easier. They don't use BC or AD
> notation, but instead use positive and negative signs (+2009, -54...). They
> do decal from historic dates. That is, what they call year -1 is what
> historians call 2BC.
>
>
> OK, I see what you mean. That's a fine approach as long as we're clear how
> the under the hood encoding of dates maps to the human-consumable dates
> which will be expressed in terms of AD and BC (or CE and BCE). The only
> concern I have with that approach is that I think authors will often make
> errors: for example, using -0007 to designate 7 BC instead of 8 BC.
>

That is the issue I see with this now. This approach (0000 = 1BC, 0001 =
2BC) is the one that looks, but yes I foresee frequent among authors. If we
do allow year 0000 but do not introduce a decal (0001 = 1AD, 0000 = nothing,
-0001 = 1BC) we introduce a complication for programs which are going to
extract the data for calculations. If we forbid year 0, then we are
restricting some authors from using, and we still introduce the problem from
the previous sentence.


>
>
> For a starter: http://en.wikipedia.org/wiki/Year_0
> (Before someone debates over Wikipedia, I have never considered Wikipedia
> as THE reference, but always thought it was a good starting point, from
> which one serious enough can go an do more researches.)
>
>
>>
>>
>>  What if year 0 is accepted as a valid date for the purpose of HTML, and
>>> then not used by authors? It would become available for those authors who
>>> use year 0, and ignored by others. Whats the implication?
>>>
>>
>> If I understand current proleptic Gregorian calendar use correctly (such
>> as that used by astronomers) the implication is that HTML will not match the
>> other uses of that calendar. ISO 8601 has unambiguous leap year rules which
>> are to be applied to 000 and negative years as well. If we accept year 0,
>> then -0001 would mean 2 BC. That's fine, but we need to make it clear to
>> authors and there's some concern authors would make the mistake of thinking
>> -0001 was instead 1 BC.
>
>
>>
>>  HTML parser does not perform math over dates, it merely displays
>>> information based on what an author instructed.
>>>
>>
>> However, if the UA displays the information in a non-machine readable
>> form, how does it make that conversion for presentation purposes. Does
>> 0000-01-01 get displayed as 1 January 1 BC? Or as 1 January 00?
>
>
>
> 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.
>
> But after reading your comments above and below (in particular the place
> where you mention the possible use of a HTML file for something other than
> displaying to a reader), and checking a few more pages on the web, I now
> understand it does in fact matter whether or not a year 0 is used.
>
>
> Yeah, the main purpose of the 'datetime' attribute and the ISO 8601-like
> encoding of dates is for extraction and use elsewhere. The contents of the
> 'time' element are simply displayed. I would like to see the 'datetime' also
> used for localized dates regardless, using CSS or another presentational
> mechanism. However, obviously that's not a part of the HTML5 project (at
> least not currently). However, there's really no reason to encode the dates
> in the 'datetime' attribute unless it can be extracted and used in a precise
> machine-consumable form. Supplementing the date with a keyword prefix or
> suffix permits even more precise date representation.
>

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>.

This software was released on <time datetime='2009-03-15'>.

In this case, the entire <time> tag is replaced by the string "February
15th, 2009" or equivalent, as above. In this case I'm not sure a tool tip
would be any useful.


>
>
>
>
>>
>>
>>  Here his the only debate I see over this:
>>> ISO 8601:2000 and above suggest that year 0000 be used and be considered
>>> year 1 BC, and then -0001 is 2 BC, etc.
>>>
>>
>> Could you cite specifically where you get that from ISO 8601:2000? I'm
>> looking at ISO 8601:2004 and don't see a clear indication of that anywhere.
>
>
> Actually never mind this. I have never read the actual ISO, but rather some
> other website which gives a detailed, human readable summary of the ISO. I
> will however read the actual ISO very soon now, as I got an interest in it
> now but haven't had time yet. I will return to that if I then fell the need
> to. I will take that you have actually read the ISO and haven't found a
> mention of year 0.
>
>
> It references year 0000 in a note, but only to remind that 0000 is a leap
> year according to the leap year rules. It doesn't discuss how it maps to the
> AD/BC human-consumable dates. Nor does it discuss how to interpret negative
> years.
>
>
>
> The reason I suggested that we only allow extended version (with hypens),
> is for the following two reasons: Allow both lower granularity dates and
> more than four digit years. If I use the date "99120412". It is "April 12th,
> 9912" or "April of the year 991204" (lower granularity with no day) or even
> just "The year 991204"? With mandatory hypens, it becomes clear: 9912-04-12
>
>
> Personally, I'm fine with that. As I said earlier, someone else (I think
> only one person) objected to requiring hyphens at all when I wanted to
> require hyphens only for the non-four-digit year cases. I think he was
> thinking we should eliminate all of the lower granularity cases (though I do
> not agree).
>
>
>
>
>>
>>
>>  - Allow non Gregorian calendars?
>>> There are actually two debates on this issue. One is whether to allow
>>> other calendars as the datetime attribute values, the other is to always
>>> have the datetime attribute value specified as a Gregorian date while adding
>>> a new attribute which would indicate what calendar is used for the content.
>>> I would personally go against the use of any non Gregorian calendar at all,
>>> since I do believe the use cases are too few. However if it is considered
>>> that the use of non Gregorian is to be supported, I would go with the later
>>> solution (allow non Gregorian as the content only, and have the datetime
>>> attribute always defined as a Gregorian date), since that would not put much
>>> complication on the parser (which does not have any calculation/conversion
>>> to perform, leaving that to the author). The new attribute would then be
>>> used by the browser to tell what calendar is used, but the datetime
>>> attribute is still used to indicate to the user the Gregorian equivalent. I
>>> do see too many problems with accepting non Gregorian as the value of the
>>> datetime attribute: too many calendars are way incompatible (try to
>>> represent a Mayan Long Count calendar),...
>>>
>>
>> We don't need to concern ourselves with how the Mayan Long Count calendar
>> works.
>
>
> No we don't but this is an example of a non Gregorian calendar which some
> authors might want to use on a web page
> <time calendar='mayan' datetime='2009-03-14'>12.19.16.3.2</time>
> <time calendar='mayan' datetime='12.19.16.3.2'>12.19.16.3.2</time>
> Get what I mean? :)
>
>
> I see. I wasn't saying we should disallow Mayan Long Count calendar only
> that we could leave it up to another subsequent specification. In that way,
> the following would indicate the date:
>  <time datetime='Mayan_12-19-16-03-02'>12.19.16.3.2</time>
>
> Since UAs would not be required by the HTML5 recommendation to support the
> keyword "Mayan" (only required to support omitted keyword or keyword
> "Gregorian"), most UAs would simply ignore the machine readable date. Many
> authors would therefore opt to convert the date to Gregorian before encoding
> it. However, due to issues like disputed conversions (like those you raise
> below), HTML5 should support machine readable dates in alternative
> calendars. In other words UAs MUST support Gregorian calendar dates. UAs
> must parse calendar prefix keywords. UAs MUST treat dates without a keyword
> as Gregorian (or with some heuristics to account for mistaken authors). UAs
> MAY support other keywords (which would be associated with subsequent and
> separate specifications). These suggestions therefore do not add any burden
> on HTML5 UAs (except the ability to parse out prefix keywords). However,
> these criteria properly abstract HTML5 to allow support for alternative
> calendars without trampling or conflicting with Gregorian dates.
>
>
> I think the first case is most easily useable, but I do understand your
> point:
>
>
>> First of all, the concerns raised are largely over Julian and Revised
>> Julian calendars. Other calendars of concern include Hebrew, Islamic and
>> Buddhist all of which are used today as civil calendars. The other concern
>> is that without clearly defined Gregorian and other calendars (and for some
>> periods in history all of these calendars lack clear standards that map the
>> representation unambiguously to a specific day on the Earth), it is more
>> accurate and precise for authors to encode a date within the precise
>> calendar than to attempt conversion (which is a lossy operation in that
>> case). Conversion is better handled at runtime by UA algorithms that keep
>> constant with the state of standards (but that requires some kind of keyword
>> differentiation of non-Gregorian and even clearly Gregorian dates).
>
>
> A mesoamerican historian might prefer to use the mayan long count without
> wanting to convert to a Gregorian date for the purpose of marking up with
> HTML. Also, to cover your other point, the Mayan long count calendar is
> generally aligned on August 11, 3114 BC, but some other historians think
> this date if off by a few days, so perhaps a future generally accepted epoch
> date might be different. All the points to you, your opinions seems very
> reasonable to me. Now my concern is still the same, I wonder how easy it
> would be to implement (actually, I think it would be very difficult). But
> well, I don't disagree that having access to non Gregorian calendars is very
> useful. But here we need to find a way, one which is easier to implement,
> and still easy enough for authors.
>
>
> I think the keyword prefix (or suffix or separate attribute value) makes
> all of this easy to implement and author. HTML5 UAs would only need to parse
> in such a way that keyword prefixes do not get in the way. HTML5 UAs would
> be required to recognize the "Gregorian" keyword (the meaning of the "Mayan"
> keyword might be defined by another specification, but an HTML5 UA would not
> be required to support it, only to not get tripped up by it or assume it
> preceded a Gregorian date). I don't think expecting UAs to be aware of an
> ignorable keyword prefix is any great implementation difficulty, but it does
> provide a more future-proof design (and is better and clearer for
> authoring).
>

Wah! Suffixes and/or prefixes are harder to read and add a burden on the
parser, don't they? A new attribute (such as "calendar='julian'") makes more
sense to me.


>
>
>
> What about those 'other calendars of concern'? Are they reasonably
> compatible with Gregorian, or so much different that my example of the Mayan
> long count becomes a good one? I know nothing about those, but I fear it's
> the later.
>
>
>
> The reason I was listing those calendars is because they are calendars used
> as civil calendars in contemporary cultures (unlike the Mayan to my
> knowledge). I think this suggests that a specification like HTML5 aimed at
> the Worldwide Web should at least make room for those calendars (even if it
> doesn't define them). To my knowledge the Mayan is rather unique. Most of
> the others require representation much the same as the Gregorian and Julian
> calendars: year, month, day. They might still require a separate
> specification to define what those dates mean, what eras are used, how dates
> before one are handled, and perhaps how they convert to the Gregorian
> calendar (since that is usually the presumed calendar under the hood of any
> operating system). Most of these calendars have more complex rules for year
> and month length than the Gregorian/Julian calendars (though the Egyptian
> calendar is quite simple and is probably the precursor to the Julian and
> Gregorian calendars). So since the representation properties are mostly the
> same for these calendars it is easy to represent them in the form
> KEYWORD_YYYY-MM-DD.
>
> To me ISO 8601 makes two contributions: 1) provides a way to unambiguously
> represent Gregorian dates (though with a keyword added the same method can
> easily be expanded to represent virtually any calendar system date
> imaginable); 2) reiterates the specification of the Gregorian calendar
> already in existence pre ISO. The first contribution can be easily expanded
> to represent dates in any calendar system. The second contribution can
> easily be expanded to 1 AD with little controversy. However, the addition of
> a calendar system keyword allows greater flexibility down the road without
> placing any appreciable burden on UAs today.
>
> Take care,
> Rob
>


This whole debate over non Gregorian calendars is far from me. I have never
even used dates other than Gregorian in my whole life (that is, before the
discussion on this list) and thus it is very difficult for me to tell what
method is the best one. I do understand there is a need for a method,
though.

>From what you say, and from some more thinking on my part, the following
could make sense:

Have a new attribute to tell what calendar is used. The datetime attribute's
value is a date on the calendar specified in the new attribute. UAs are
required to understand Gregorian (the absence of the new attribute means we
are using Gregorian). They *may* understand other calendar, but only for the
purpose of showing them correctly (or any other task which has nothing to do
with conversion).

Does that make sense? Is it what people need? It is useful? Is it easy to
implement? Do you believe in the Yeti?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090315/54a3aab3/attachment-0001.htm>

Received on Sunday, 15 March 2009 16:07:15 UTC