HDF5: use native mtime, ctime/btime for created_at, updated_at

[gicmo]

We currently use HDF5 attributes for staring created_at and updated_at. HDF5 already provides a mechanism for recording such information automatically via H5Oget_info[1]. That times will be tracked must be ensured via the corresponding property set by H5Pset_obj_track_times.

[1] http://www.hdfgroup.org/HDF5/doc/RM/RM_H5O.html#Object-GetInfo
[2] http://www.hdfgroup.org/HDF5/doc/RM/RM_H5P.html#Property-SetObjTrackTimes

[stoewer]

This would help allot, since currently setUpdatedAt() is not invoked in some places and therefor update times are sometimes wrong.
There is only one problem: If we want to preserve the creation time, when one entity is copied from one fine to another, we must find a way to overwrite the ctime inside the hdf5 file.

[balint42]

not sure if I understand the issue: why & when to copy an entity from one file to another?

[gicmo]

I had a look into[1] this and it is quite disappointing. Apparently support for everything but ctime for datasets is lacking:

% ./playground                                                               [master|◯]
--- group
atime: 0 Thu Jan  1 01:00:00 1970
mtime: 0 Thu Jan  1 01:00:00 1970
ctime: 0 Thu Jan  1 01:00:00 1970
btime: 0 Thu Jan  1 01:00:00 1970
---
--- dataset
atime: 0 Thu Jan  1 01:00:00 1970
mtime: 0 Thu Jan  1 01:00:00 1970
ctime: 1393954764 Tue Mar  4 18:39:24 2014
btime: 0 Thu Jan  1 01:00:00 1970
---
--- file
atime: 0 Thu Jan  1 01:00:00 1970
mtime: 0 Thu Jan  1 01:00:00 1970
ctime: 0 Thu Jan  1 01:00:00 1970
btime: 0 Thu Jan  1 01:00:00 1970
---

See also this conversation from June, 2012: [2]

This is basically a showstopper for this bug -> not a target for Milestone First Alpha.

[1] Compete hack as a test: https://gist.github.com/gicmo/9351530
[2] http://permalink.gmane.org/gmane.comp.programming.hdf/3580

[jgrewe]

Indeed a bit disappointing and I would not like to implement created_at in a different way than the updated_at time-stamp...