Time Ranges and Calendars

Although the different NA-CORDEX simulations cover the same time periods (1980-2014 for ERA-Interim, 1950-2005 for historical, and 2006-2100 for future simulations), the exact start and end dates vary depending on a variety of factors, including the limits of the driving boundary conditions, the format of the inputs, and how the model handles missing inputs.

The simulations also vary in terms of the representation of the annual cycle. The ERA-Int runs all use the standard (aka "gregorian") calendar, which has 365 days per year or 366 in a leap year. Some of the GCM-driven runs also use the standard calendar, but some of them use a 365-day or "noleap" calendar in which the lenght of the year is a uniform 365 days, with no leap years. A few runs (some of those driven by HadGEM) have a 360-day calendar, with 12 months of exactly 30 days each.

All the data files represent time in the same way: as a count of days starting from some baseline, where the time coordinate has a value of zero. To properly convert the numeric time coordiante to a date, you must consider the calendar (which tells you how many days are in the year) as well as the baseline that it's counting from.

The calendar and the baseline are recorded in the netcdf metadata as the attributes calendar and units of the variable time. If possible, it's good practice to use tested software to do the conversion rather than doing it by hand; NCL has the cd_calendar function, Python has the cftime library, and R has the stars package. Note that standard datetime libraries generally do not understand the special calendars used in climate models, and that incorrect interpretation of the time coordinate can generate signficant errors. (Treating the 360-day calendar as standard results in an error of 16 months after 100 years, and even the 365-day calendar is off by almost four weeks at that point.)

For convenience, the following table lists the calendar, number of timesteps, date of the first and last timestep, and baseline for each simulation in the NA-CORDEX archive.

Note 1: A few simulations end at 10:30 instead of 12:00. In these cases, the sub-daily simulation data was missing a single timestep at the end, and stopped at 21:00 instead of 24:00, and the time coordinate is placed at the midpoint of the time interval. 10:30 is the midpoint of 00:00 to 21:00.

Note 2: Be cautious about data from the first few years of the historical GCM-driven simulations. RCMs take some time to reach a state of dynamic equilibrium, and depending on how the modeling group handled this "spin-up" period, these years may still have imbalances due to initial conditions.

Note 3: The HadGEM2-ES GCM uses a 360-day calendar. The 360-day calendar has 12 months of 30 days each, so Dec. 31 is not a valid date under that calendar, while Feb. 30 is. The RegCM4 simulations driven by HadGEM preserved the 360-day calendar, but the WRF simulations converted it to a gregorian calendar by interpolating the boundary condition data to match: Feb. 30th and 29th (except in leap years) were dropped, and the 31st of Jan, Mar, May, Jul, Aug, Oct, and Dec were interpolated from the days before and after.