gavinmacaulay
commented
4 years ago The sonar-netcdf4 format still specifies nanoseconds, but as per the CF convention, the format is given in the 'units' attribute so could in theory be any format supported by the UDUNITS library.
There is a Python library that converts CF convention time formats into Python datetime objects (https://unidata.github.io/cftime/) but this doesn't support nanoseconds (it only goes down to milliseconds). Am unsure what is available for other languages.
Milliseconds are probably accurate enough for echosounder ping times, but nanoseconds were used because the EK60 and EK80 data files use Windows timestamps which are to 100 nanoseconds. But, while the UDUNITS time format allows for a time unit of 100 nanoseconds, many UDUNITS libraries don't support the 100 part, hence the use of 1 nanosecond as the base step for sonar-netcdf4.
There are several options which reflect an increasing awareness of things since the sonar-netcdf4 format was written:
- Change sonar-netcdf4 to state that any UDUNITS time format is ok, but recommend some sensible ones and expect all reading/writing software to read and interpret the 'units' attributes (this is how all existing netCDF reading software is supposed to work).
- Specify nanoseconds for all formats (and fix the contents of the 'units' attribute)
- Specify milliseconds for all formats (but lose resolution when storing data from EK60/80 files)
In the ICES sonar-netcdf documentation version 1.0, the units of the timestamp is nanoseconds since 1601-01-01. (Or has this been changed?)
In the interpretation mask netcdf, the timestamp is in milliseconds since 1601-01-01.
I think the timestamp between the raw files and the interpretation files should have identical format.