----- Original Message -----
From: Tab Atkins Jr.
To: Pentasis
Cc: [EMAIL PROTECTED]
Sent: Tuesday, November 25, 2008 4:44 PM
Subject: Re: [whatwg] Issues relating to the syntax of dates and times
On Tue, Nov 25, 2008 at 7:36 AM, Pentasis <[EMAIL PROTECTED]> wrote:
Ian Hickson wrote:
While I could see that maybe one day there'd be a use case for <time> that
would need historical dates, I really think that we'd have to tackle other
calendars in use today before looking at calendars that aren't in use
anymore. So I'd rather punt this for now.
While it is true that there are to many factors to take into account
regarding which calendar, which era, etc.
I can also imagine, (just brainstorming here) if I look at this example in
the spec:
<p>We stopped talking at <time datetime="2006-09-24 05:00 -7">5am the next
morning</time>.</p>
This means I should also mark up something like this:
<p>It was <time datetime="???">5 seconds after the big bang</time>.</p>
"5 seconds after the big bang" is an exceedingly ill-defined time, though.
Currently you'd be lucky to peg it within a billion years of the accurate time,
ignoring any relativistic issues with timekeeping. This was Ian's point about
far-past dates being nearly never exact enough to justify a machine-readable
timestamp.
There are more factors to take into consideration in this example than just
calendars.
So... Wouldn't it be far more efficient and convinient to have a
construction by which we can set a "base-date/time"? (something like the
base-url-thing). That way you can set the date/time to anything at all based on
a reference-setting. And this reference setting could be anything (another
calendar, a specific point in time (or perhaps even time-space) or a relative
reference. I don't think this would have to be dealt with by the UA but can be
done by scripting.
How does this solve the issue of the base time being too ill-defined for a
timestamp? Assuming you have a basetime of "the big bang", you can certainly
exactly specify exactly 5 seconds after, but how would you specify the basetime?
You're just moving the issue one level back. This doesn't solve the
underlying issue that far-past dates aren't exact enough to give them a
timestamp. This problem requires an entirely different solution, and trying to
shoehorn it into a timestamp-based solution just gives you two bad solutions.
~TJ
No, actually you (and Ian) say it yourself. Dates and times far-in-the-past
can *never* be exactly defined. So we should instead settle for a relative or
approximate base if we cannot provide for an exact one. In the example of the
big bang I could set the base-time either to be "big-bang" or "according to
theory x". To name but a few. The advantage of this is that the actual "exact"
date/time can then always be re-calculated as we acuire more knowledge about
the date in question without having to re-mark-up the whole thing. (but only if
we want/need it).
The fact remains that dates and times can *never* be exact. Besides why would
we need that in mark-up language? What benefit is it to HTML and UAs if dates
and times are all based on one base?
I would much rather have a construct by which I can at least set a date which
makes sense in some way and I can rest easy to know that this will
"automatically" become more and more accurate (according to the than used
universal base-time-code) as science and knowledge evolves.
I do not have to specify the base-time as you put it, why do I have to? How
would you define UTC for that matter? Sure there is a definition for it, but
that is also only valid based on other agreements (UTC has no meaning when
traveling at the speed of light between Jupiter and Magellen I think). Besides,
the UTC timing will also be "ill-defined" someday in the future, so current
date/times are no different (relativelly speaking) from far-past-dates.
Another advantage of this is -I just realized- that one could mark up time in
a fictional article with fictional dates.
But, I will concede to the fact that this may make things more difficult. But
in that case I would ask for the definition of the spec to be changed from "The
time element represents a date and/or a time." into something more restricting
and exact which at least represents the limitations of this element that are
presented in this discussion. Or better yet, drop the element as it makes no
sense (IMO).
Bert
