Derrick,
Did you check to see that your NCL, ncview, and ferret are both using
recent versions of udunits, if not the latest? I recall a past warning
about problems in older udunits versions with pre-Gregorian dates.
http://www.unidata.ucar.edu/packages/udunits/known_problems.html#pre-Gregorian
The ut_calendar documentation (NCL) includes a caveat about the
Gregorian calendar transition, though you should otherwise expect your
software to handle the transition in a consistent manner:
http://ngwww.ucar.edu/ngdoc/ng/ref/ncl/functions/utcal.html
(See paragraph under "Description".)
Also, my habit is to avoid the Gregorian calendar transition altogether
when working with data containing only "modern" times (1600 and up). So
I will base my time coordinates something like "since 1800-1-1". I
think this approach is suggested in some of the netcdf conventions.
Modern tools like NCL and ferret should be able to handle this with
little or no extra effort, though my experience in this area is limited.
Perhaps this approach would help in your case.
--Dave A.
CDC/NOAA/CIRES
Derrick Snowden wrote:
> Hi all,
>
> I am hoping some guru out there has stumbled across this quirk before...
>
> Regarding the ut_calendar function, I have a netcdf file with the time
> units attribute defined as
>
> time@units = "Days since 0000-1-1 00:00:00 -0.00"
>
> These data were created in Matlab using the Matlab default function
> datenum. This calendar function creates a serial date which is defined
> exactly as above, at least that's what the documentation says. If I
> generate a plot in ferret (another graphics package which deals with
> netcdf files) I get what I'm looking for. That is the serial date
> number (for example 731200.0000 corresponds to Dec 15, 2001) is
> interpreted correctly and parsed into a string etc. In NCL I try
>
> time = 731200.0
> time@units = "Days since 0000-1-1 00:00:00 -0.00"
> print(ut_calendar(time,0))
>
> and get
>
> (0,0) 2002
> (0,1) 12
> (0,2) 15
> (0,3) 0
> (0,4) 0
> (0,5) 0
>
> which is advanced by a year. The ncview utility, gives the same
> interpretation as NCL, which I understand, is because they are both
> based on udunits. The strange thing is that so is ferret. Any
> suggestions?
>
> I know there is a temporary work around by defining a new serial date
> vector using greg2jul and jul2greg. However, I exchange files regularly
> with ferret users. It would be problematic if we are constantly
> distrustful of the date functions. Any ideas are appreciated...
>
>
> best,
> Derrick
>
_______________________________________________
ncl-talk mailing list
ncl-talk@ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
This archive was generated by hypermail 2b29 : Sun Dec 21 2003 - 16:04:29 MST