"time time said old king tut is something i aint got nothing but"
-Don Marquis
I have a problem with time. I have netCDF and the udunits packages. I want to
be able to write time-dependent meteorological datasets where the time is
hours, minutes, and seconds, either local or Zulu time.
I would like to do this, satisfying these conditions:
A) I would like to do it in a standard, de facto standard, or quasistandard
way.
B) I would like my visualization program to be able to figure out, just by
looking at the file without my having to press buttons, that the time should be
displayed as hh:mm:ss.
C) I don't want to built into my visualization program assumptions that would
bias it against non-meteorological or non-HMS data.
This is such a common problem that I'm sure that somebody in the world has
tackled it. If one of you have done so, please let me know what you have
decided. I really don't want to do something in such a way that I'm the only
one doing it that way.
Here are some of the possibilities that I have come up with, in roughly
increasing order of silliness and exasperation:
1) Use time as the unlimited variable, using the udunits mechanism to provide a
single linear unit (e.g. "fortnights since 1776-7-4 8:37"). Then have an
attribute called something clever like "format" that gives the printing format
of the time. This possibility is subdivided into
1a) Use some standard perfect format that somebody here has figured out.
1b) Use the format that I'm already using internally, which is basically
printf with the letters changed to indicate bits of the time (e.g.
"%2.0h:%02.0m:%02.0s"
1c) Use the format used by some of the UNIX functions, which is also like
printf but is a little bit different from mine.
1d) Make up some intuitive but possibly not infinitely flexible format
(e.g. "hh:mm:ss").
2) Use the hour, minute, etc. variables. This is sort of nonstandard because
it doesn't use the unlimited variable, which is supposed to be used for time.
Then I have the choice of making these scalars, in which case I would be
limited to one time step per file, or making them vectors, in which case I
would be unable to use unlimited dimensioning. Because my vis program
assembles datasets arbitrarily with timesteps in any order at read time, I
don't care internally.
3) Extend the units convention so that the hhmmss nature of the data can be put
in the unit. Then the time variable could continue to be a real number, but it
might be a number like "1204.0" meaning four minutes after 12.
4) Use the time unlimited dimension but make it a string with syntax. Then, if
I see "12:04" I know it's hh:mm, if I see "37.6" I guess it's seconds, etc.
This is a really disgusting idea, but I already have the string parser.
5) Say, "aw, to hell with it" and use the dataset name convention that I use
for all data formats that don't have time-dependency, where you write
"foo@12:04" to mean a dataset named "foo" at time "12:04."
What do y'all think?
Also, is there such a thing as a udunits document?
Eric Pepke INTERNET: pepke@xxxxxxxxxxxx
Supercomputer Computations Research Institute MFENET: pepke@fsu
Florida State University SPAN: scri::pepke
Tallahassee, FL 32306-4052 BITNET: pepke@fsu
Disclaimer: My employers seldom even LISTEN to my opinions.
Meta-disclaimer: Any society that needs disclaimers has too many lawyers.
