[whatwg] Issues relating to the syntax of dates and times
pentasis at lavabit.com
Tue Nov 25 08:39:21 PST 2008
----- Original Message -----
From: Tab Atkins Jr.
Cc: whatwg at whatwg.org
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 <pentasis at lavabit.com> 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.
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the whatwg