Having slept on it... Was: Alternative calendars and holidays, moon phases etc.

On Thu, 12 Apr 2001, Jan Grant wrote:

> On Thu, 12 Apr 2001, Charles McCathieNevile wrote:
> >
> > No, I don't think it is accurate. I think it is a design decision about
> > whether we want a single point of reference or whether we can do without one
> > on the assumption that the distributed systems of reference will work. I
> > assert that we can do the latter, and that we can then use your proposed
> > single reference as just one possiblity in a distributed framework, and add
> > trust semantics to the user interfaces we create that allow me to choose
> > whether I trust the US navy as a keeper of that or whether I trust the
> > moon-tracking machine I want to install at home one day with the clockwork
> > backup, or whether I just believe my computer's clock all the time.
>
> The point I'm trying to make is that there is a danger of
> over-engineering this. There's lots of scope for complicating solutions,
> but in this case it isn't necessary; if you pick a fixed point in the
> past then everyone in the world will be able to agree how many seconds
> have elapsed since that moment in time.

Thinking further about this, maybe there _is_ a need to describe
scheduling/date-calculating algorithms. If you have a recurring event
that's generated by a rule (meta-event) that says "once every blue
moon..." and I'm looking for the next three occurrances of this, I
_could_ just ask you to supply the dates; you could do the calculation
and give me the answers (this was my original point of view). This is
all you need to do to support scheduling.

However, if I want to do a bit more reasoning about what you're up to,
and I don't want my reasoning to descend into a hideously distributed
mess, then you need to be able to describe _how_ you chose the dates in
question, not just what those dates are. Whether you can do this with
something less than turing-complete, I dunno. My initial instinct was
that the algorithm to determine those dates (as far as I am concerned)
should simply be:

	ask Charles for the dates of the _n_th occurrance of
		such-and-such an event.

There may be an out-of-band way for me to get more than this; for
example, I could also

	ask Charles for the java bytecode of the class that
		calculates the _n_th occurance of this event

- replacing "java bytecode" with "prolog", "lisp", etc. ad lib - but
this latter operation is not required for the day-to-day organisation of
meetings between Charles and myself.

(This has less to do with scheduling than with reasoning built on top of
a calendaring data model.)


-- 
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
Strive to live every day as though it was last Wednesday.

Received on Friday, 13 April 2001 06:20:14 UTC