- From: Jan Grant <Jan.Grant@bristol.ac.uk>
- Date: Thu, 12 Apr 2001 15:23:09 +0100 (BST)
- To: Charles McCathieNevile <charles@w3.org>
- cc: Danny Ayers <danny@panlanka.net>, www-rdf-calendar <www-rdf-calendar@w3.org>
On Thu, 12 Apr 2001, Charles McCathieNevile wrote: > It needs a way of relating one clock to another that can be daisy-chained, so > I can get from yours to mine and back. I hate to say "that's a user-interface issue" - especially since that sentence isn't exactly accurate; see below. > And of stating that Something happens at particular points of a given clock. Agreed; calendar "agent" work. > On Thu, 12 Apr 2001, Danny Ayers wrote: > > <- In a single sentence: > <- Attempting to teach a calendaring _protocol_ about local holidays is > <- pointless because such notions should be subsumed in a more general > <- mechanism for deferring the management of your available time, etc, to > <- external agents. > > In other words, all the protocol needs is a standard clock? Yep, a standard clock and the intelligence in the apparatus that the user sees (or that acts on his behalf) to interpret and present that clock appropriately. Clearly, work needs to be done pulling the bits and pieces that do lunar calculations, equinoxes, Jewish holidays, etc. together but that information can be _derived_ from (eg) time in seconds since Midnight, Jan 1, 1970* "All life is calendaring". That's why the problem is interesting - there are lots of plausible (doable) engineering solutions but you can go on making the problem harder and harder as it takes your fancy. jan * To pick a (completely arbitrary) point in time as a ferinstance, -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk Talk is cheap: free, as in beer. As in Real Ale, not that Budweiser rubbish.
Received on Thursday, 12 April 2001 10:24:09 UTC