Hi, A follow-up question to the time thread of a couple of weeks ago: Is anyone considering a "convention" for implicitly saving time for variables that are stored at regular time intervals? As an example, consider N salinity measurements, salt(time): time(1) salt(1) time(2) salt(2) . . time(I-1) salt(I-1) time(I) salt(I) time(I+1) salt(I+1) . . time(N) salt(N) where time(I+1)-time(I) = deltat, 1 <= I <= N-1 and deltat is a constant. The time array can be reproduced by storing only three numbers: time(1), N and deltat. It would be nice to save space by storing these numbers instead of all N times. One possible solution is to store attributes of the array salt that look something like: salt:time_base = time(1); salt:time_increment = deltat; This works, but imposes two new attribute "conventions". Note: N is is the dimension of salt, and, therefore, is already stored using standard netCDF means. Another possibility is to retain time as a variable, but dimension it to have only 1 element and assign NaN or FloatInf or whatever to it. This would permit an attribute definition more in-line with the time conventions that seem to be emerging from the discussions a couple of weeks ago. An example would be: time:units = deltat @ time(1); No new attribute conventions are imposed, but this requires the implicit assumption that, if time is a 1-element empty array, the times are to be reproduced using the units attribute. Any suggestions, comments? Note: The problem of saving space by storing only a base and increment for a coordinate variable can be extended to regularly-spaced (gridded) data in multiple dimensions. However, the stored grid becomes a much smaller part of the file as the number of dimensions increases. As an example, a 4-d salt array might be regularly-spaced in time, x, y and z, and stored in a KxLxMxN array where time is Kx1, x is Lx1, y is Mx1 and z is Nx1. For large K,L,M and N the sizes of time, x, y, and z become a non-issue for reducing file size since salt will be proportionally larger. Therefore, the 1-d example case is likely to be the most important one, since storing time as time(1) and deltat reduces the file to just larger than half its size, as N gets large. -- Harry L. Jenter hjenter@stress.er.usgs.gov U.S. Geological Survey COM: (703) 648-5916 FTS: 959-5916 Mailstop 430, National Center "Sometimes you're the bug. Reston, Virginia 22092 Sometimes you're the windshield."