NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Time:
We at SSESCO have decided to implement our netCDF time storage as
a string basetime (ala udunits) "UNITS since 1994-01-14 9:06:01.1 -6:00"
and a double float offset from that which can be any units set in the bastime.
Our visualization software expects the time/date to come in as a
unix-time format (seconds since 1970) so we wrote some conversion
routines.
Liam Gumley writes:
> I agree that using Julian Day, and number of milliseconds since midnight of
> the Julian day is a good way to store time data.
>
> However, does it introduce some possible confusion? The following is from
> "Numerical Recipes in C", 2nd Ed., p. 12.
>
> "Astronomers number each 24-hour period, starting and ending at noon, with
> a unique integer, the Julian Day Number."
>
> That is, Julian Day Number 2440000 starts at 1200 GMT on 23 May 1968, not
> at 0000 GMT.
>...
This could be resolved by adding a basetime string to the variable
idicating whether the basetime was 1-1-1 12:00:00 -5:00 or 1-1-1 0:00:00 -5:00
..
what are the limitations to the 'udunits' approach that we have used?
--
bcl
blincoln@xxxxxxxxxx
----------------------
SSESCO: (612) 342-0003
netcdfgroup archives: