Re: Updated group API changes draft

"Robert E. McGrath" <mcgrath@xxxxxxxxxxxxx> writes:

>  From talking with Quincey, I would like to point out a couple of areas
> where people might want to look carefully. 1. H5Gmove, etc.
> Technically, time stamps are set when an object is inserted in a group.
> And technically, H5Gmove is an atomic (delete, then insert).  So it
> should
> set the time stamp to the time of the move.
> Quincey proposes to not update the time.
> There are arguments for either behavior, so it would be good for
> people to
> look at this carefully.

I will leave this to you HDF5 programmers. NetCDF doesn't allow moves,
so I don't use H5Gmove.

> 2. H5Gset_creation_time
> This is a funny function that let's you manually set the timestamp on
> a given link.  I'm not sure we need this at this time.
> As far as I know, we don't have any use cases for this feature.
> To me, it is philosophically questionable, because the timestamp isn't
> supposed to be
> "whatever I want it to be", it is supposed to be "the time I really
> did it".
> Also, I can think of at least 2 pernicious uses of this feature:
> a) somebody my use this timestamp as a back door way to create an
> arbitrary
> numeric index.  E.g., compute some statistic in the dataset, and set the
> timestamp to that value.  Voila! I have an index on that statistic!
> b) somebody might do something horrid like store every record in a
> separate
> dataset, setting the time step from some source such as a real time
> clock
> or network time stamp. They are trying to get time sorted records (think
> of Boeing, merging multiple real time streams.)  This would kind of
> work,
> but I think it would be a really bad use of HDF5.
> Again, others may well have different opinions, so it would be good for
> people to look at this one.

I think you should store an index, not a time-stamp. Do not let the
user change the index under any circumstances.


Ed Hartnett  -- ed@xxxxxxxxxxxxxxxx