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
