Re: Schedule decision

> At 10:16 AM 4/19/2005, you wrote:
> > > Quincey Koziol <koziol@xxxxxxxxxxxxx> writes:
> > >
> > > >     I was planning on including a hidden field to disambiguate 
> > objects that
> > > > were created at the same time, so this wouldn't happen.  Since there's 
> > > > no
> > > > advantage to using a creation order field instead of using the 
> > creation time
> > > > when determining the n'th object inserted into a group (when 
> > factoring deleted
> > > > objects into the equation), I'm still leaning toward using a time 
> > instead of an
> > > > index for this purpose.  Using the time provides the same 
> > functionality and
> > > > adds information as well.
> > > >
> > > >     I'm still somewhat split on the issue however and would welcome 
> > persuasive
> > > > arguments in favor of one mechanism or the other.  :-)  I'm also 
> > thinking about
> > > > including both fields (creation order and creation time) and allowing 
> > users to
> > > > create an index on either, to suit their particular needs...
> > >
> > > Quincey,
> > >
> > > What happens is a machine with an inaccurate time adds a variable to a
> > > dataset?
> >
> >     It'll get the "wrong" creation time and inserted in the index
> >appropriately, as you'd expect.  I don't think this is a major problem 
> >though,
> >because I don't think that most files will get edited on multiple machines in
> >a very short timeframe.
> 
> This will happen in parallel computing systems. Even cluster nodes can be
> off from each other a few seconds.  And then the Grid computing will
> make it even worse as machines will be in different time zones and bigger
> time latency.

    Actually, I don't think it'll be a problem in parallel systems, because only
one processor will be writing the metadata to the file and the metadata will
reflect that machine's time settings.

    Quincey