[Thread Prev][Thread Next][Index]

Re: [las_users] "noleap" calendar not recognised by addXML


Give 1.3 a try. You may find that you're not happy with the way the times get written into the file. The software tries to find the minimum information need to distinguish the different time steps. Since yours are steps of a year, it only writes the year which may cause problems further down the line in LAS. So, you might need to use the new -f option to specify the format of the date string that gets written to the XML file. Example below.



addXML.sh -n ~/data/csiro.nc -f "yyyy-MM-dd"


<id-1b0c6b5f1f name="CSIRO model output prepared for IPCC Fourth Assessment" url="/home/porter/rhs/data/csiro.nc">
<fd-id-1b0c6b5f1f name="Total Number of Frost Days in Year" units="days" url="#fd">
<link match="/lasdata/grids/grid-lon-lat-time-id-1b0c6b5f1f" />
<link match="/lasdata/axes/lon-x-id-1b0c6b5f1f" />
<link match="/lasdata/axes/lat-y-id-1b0c6b5f1f" />
<link match="/lasdata/axes/time-t-id-1b0c6b5f1f" />
<lon-x-id-1b0c6b5f1f type="x" units="degrees_east">
<arange start="0" size="192" step="1.875" />
<lat-y-id-1b0c6b5f1f type="y" units="degrees_north">
<time-t-id-1b0c6b5f1f type="t" units="year">
<arange start="2001-07-17" size="60" step="1" />

Glenn Hyland wrote:

Thanks very much for the update.

I've run the latest version over a small sample of files, and I no
longer get a whole bunch of "Too many periods: ..." error messages.
However, the dates listed in the xml file are still not correct. For
example, a time value of 730380.5, which is 2001-Jan-15 12:00:00 in the
no_leap calendar, is listed in the xml file as

<arange start="2000-09-23 12:00:00" size="120" step="1" />

So addXML seems to be using the correct calendar to calculate the time
periods (daily, monthly etc), but is still printing the dates to the xml
file using the wrong calendar.

Once again, thanks for your help.


On Fri, 2006-12-08 at 22:14 -0600, Roland Schweitzer wrote:

Hi Glenn,

With a little help from Brian O'Neill one of the developers at
joda-time (the basis of all the time calculations in addXML) I've
added support for most of the calendars (including noleap) in the
CF-1.0 calendar attribute. You can pick up the latest version from

>From the README:

This release adds support for some of the CF-1.0 calendar attributes.

The supported calendars are:

gregorian or standard
Mixed Gregorian/Julian calendar as defined by Udunits. This is the
A Gregorian calendar extended to dates before 1582-10-15. That is,
a year is a leap year if
either (i) it is divisible by 4 but not by 100 or (ii) it is divisible
by 400.
noleap or 365_day
Gregorian calendar without leap years, i.e., all years are 365
days long.
all_leap or 366_day
Gregorian calendar with every year being a leap year, i.e., all
years are 366 days long.
Julian calendar.

Future releases will add support for 360_day and the calendars defined
by the month_lenghts,
leap_year, leap_month if demand warrants.

I admit I did not test it as extensively as I should have which always
comes back to haunt me. Please try it for yourself and let me know
how it goes. :)


PS: joda-time is at http://joda-time.sourceforge.net/.

Glenn Hyland wrote:

I'm trying to configure LAS (v6.5.2.1) to serve up some climate model
results. These are netCDF files which adhere to the CF-1.0 convention.
The problem is that addXML doesn't interpret the time axis values
correctly. The relevant bits of information from a typical file are as

time {
String long_name "time";
String standard_name "time";
String axis "T";
String units "days since 0000-01-01 00:00:00";
String calendar "noleap";
String bounds "time_bnds";

time, 730547.5, 730912.5, 731277.5, 731642.5, 732007.5, ...

The first time value corresponds to the 30 June 2001, but addXML
generates dates starting in 2000. It has obviously ignored the "noleap"
calendar setting.

Has anyone encountered this problem before, and is there a

Thanks for your help.


[Thread Prev][Thread Next][Index]

Dept of Commerce / NOAA / OAR / PMEL / TMAP
Contact Us | Privacy Policy | Disclaimer | Accessibility Statement