[whatwg] Fwd: <time>

[Tom Duhamel]

Re posted because accidentally posted offline (well even I can do
mistakes...)

---------- Forwarded message ----------
From: Tom Duhamel <tom420.duhamel at gmail.com>
Date: Sun, Mar 15, 2009 at 1:50 AM
Subject: Re: [whatwg] <time>
To: Robert J Burns <rob at robburns.com>


(I saddly stripped down this very long post to only the parts relevant to my
replies, but really if you are currently reading this from an archive 10
years from now find and read the original post, Rob really has a lot to say
and I'm looking forward to read more of his ideas and opinions)
On Sat, Mar 14, 2009 at 8:01 PM, Robert J Burns <rob at robburns.com> wrote:

>
> Use ISO 8601 with the following provisions:
>> - Allow all four digit years, positive and negative
>>
>
> We cannot agree on this unless we go beyond ISO 8601 and define how those
> representations map to BC/BCE while also keeping consistent leap year rules
> in place (note this is an area that does require some calendar expertise).
>
>> - Allow lower granularity dates: 2009-03-14, 2009-03, 2009
>>
>
> Agreed
>
>  - Allow ranges: 2009-03-01/2009-03-14
>>
>
> Agreed
>
>> - 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.


>
>
>  I'm not sure many have arguments against any of the above. Sorry if I
>> missed anything. I don't claim we have actually reached a consensus.
>>
>
> I would add that keyword support for alternate calendars is an important
> part of keeping options open for HTML6 and also to help reduce authoring
> errors.
>
>> Here are items which we are debating over, with my opinion on these:
>>
>> - Allow year 0000 or not?
>> Actually I don't see why it's important.
>>
>
> It is important because we want dates before 0001-01-01 to be encoded
> unambiguously.  If we don't address such issues we need to limit ourselves
> to 0001-01-01 and later.
>
>> I think it should be allowed. Historians deny the existence of year 0, but
>> astronomers use it.
>>
>
> It isn't a matter of denial or belief. This is an issue of precisely
> defining a Gregorian calendar to apply to the past: a calendar which was
> defined in 1582 with only the future in mind. ISO 8601 could have stepped in
> an further defined the Gregorian calendar but it punted. So no one is
> denying the year 0000 exists. The question is whether the Gregorian calendar
> should call the year before 1 AD, "year 0". Could you provide some reference
> to astronomy's used of a year 0 between 1 AD and 1 BC (for example the
> Starry Night astronomical software I use does not have a year 0 between 1 AD
> and 1 BC. I often see such claims made, but I've never seen such
> definition/use of a specialized Gregorian calendar).


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.

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.


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


>
>
>  Most, I believe, will want year -0004 = 4BC (and this is what I'd
>> suggest).
>>
>
> If -0004 equals 4 BC then that may require leap year rule adjustments to
> match other proleptic Gregorian calendars (where -0005 would be a leap year
> instead). Again the problem is that we do not have a definitive standard to
> reference for a proleptic Gregorian calendar, especially for year before 1
> AD.
>
>  - Allow 5 or more digit dates? Like year 10,000 or year 100,000 BC?
>> It's feasible: 10000-01-01, or -100000-01-01 (which is more likely to be
>> used with lower granularity I guess). I don't think this is going to give
>> parsers a greater complication.
>>
>
> That looks fine to me. Others have suggested we still allow hyphenation
> omission (which works if we exclude ordinal dates like YYYY-DDD). This would
> also then allow: "100000101" to represent 1 January 10,000.


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


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

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090315/090f4f96/attachment-0002.htm>