In my humble opinion time since epoch is not a good standard. Following is the best practice I could come up with for our time needs. We store times in ISO 8601 as UTC. You can use a decimal in the seconds field if for high resolution. Since we want to know local time where the data was captured we also store timezone info next to it but not instead of UTC. UTC is always primary. For data sets of time info we use a double with seconds since the ISO stamp. This is working well for us.
David On Thu, May 26, 2016 at 8:20 AM, Koennecke Mark (PSI) <[email protected] > wrote: > Dear Stephen Bissel, > > Am 26.05.2016 um 15:16 schrieb BISSELL, Stephen (AEROCONSEIL SA) < > [email protected]>: > > Is there any roadmap within HDF5 to implement / define a portable time > type? H5T_TIME is clearly not portable, and from python forum reports I see > that python, at least, regards HDF5 as lacking a basic time type. > Alternatively, is there a wide-spread “de facto” that most people are > using to represent time – e.g. double? > > To be clear, I’m referring to a no-frills “seconds since start of epoch” > type of time with resolution down to (at least) microseconds, which would > be used for “timestamping” data. Given the user base that HDF5 supports, > this problem must have come up many times, with more demanding sub-second > resolution. > > Currently, we use a composite, but this means that the time field always > has to be treated in a “special” way, which is unsatisfactory. And at the > most trivial level, HDFView allows a quick sanity check of data by plotting > one column against another as abscissa …. except in the case of our > composite time, where I’m limited to plotting against the seconds part of > the structure. > > > > This email and its attachments may contain confidential and/or privileged > information. If you have received them in error you must not use, copy or > disclose their content to any person. Please notify the sender immediately > and then delete this email from your system. This e-mail has been scanned > for viruses, but it is the responsibility of the recipient to conduct their > own security measures. Airbus Operations Limited is not liable for any loss > or damage arising from the receipt or use of this e-mail. > > Airbus Operations Limited, a company registered in England and Wales, > registration number, 3468788. Registered office: Pegasus House, Aerospace > Avenue, Filton, Bristol, BS34 7PA, UK. > > > we use a double calculated with the function given below: > > double DoubleTime(void) > { > struct timeval now; > /* the resolution of this function is usec, if the machine supports this > > > and the mantissa of a double is 51 bits or more (31 bits for seconds > > > and 20 for microseconds) > > > */ > gettimeofday(&now, NULL); > return now.tv_sec + now.tv_usec / 1e6; > } > > The code is for unix, of course, on windows your mileage will vary. > > Best Regards, > > Mark Koennecke > > > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > Twitter: https://twitter.com/hdf5 > > > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org > Twitter: https://twitter.com/hdf5 >
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://lists.hdfgroup.org/mailman/listinfo/hdf-forum_lists.hdfgroup.org Twitter: https://twitter.com/hdf5
