Dear Jim I don't understand why you think gregorian_nls is not sufficiently specific. I think it indicates specifically that the conversion between timestamp and elapsed seconds is done without using leap seconds.
> As an example, the date and time stamps as I'm writing this in the > different systems are: > > * TAI 2015-05-20 20:21:00 > * GPS 2015-05-20 20:21:16 > * UTC 2015-05-20 20:21:35 If you have a timestamp of 2015-05-20 20:21:35 and you encode it with calendar="gregorian_utc" and units="seconds since 1980-01-06 00:00:00" you will get the same number (of seconds) as if you encode the timestamp of 2015-05-20 20:21:16 with calendar="gregorian_nls" and the same units. Have I got that right? Thus, this would be a way to encode GPS time (the original question). The same gregorian_nls calendar can be used to encode TAI time with units="seconds since 1958-01-01 00:00:00". The same software could do both - it needs to know the Gregorian calendar, and assumes that all days have 86400 s. > Redefine 'gregorian' to remove reference to UTC as Jonathan has > described, and state that presence or absence of leap second > artifacts in the reference timestamp and elapsed time values is not > known for a time variable that names this calendar. This is backward > compatible. I don't see an advantage in encouraging data-producers to be vague. Deprecating this calendar, so it gives a warning, might persuade them to specify what they are doing to encode their times. Best wishes Jonathan _______________________________________________ CF-metadata mailing list [email protected] http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
