0

I'd like to write a NetCDF that will contain 366 days per year for all years, with the Feb 28th value repeated as the Feb 29th value in the case of non-leap years. How would I build the list/array of time values so that the Feb 29th slot contains the same time value as Feb 28th during non-leap years? Is this really what I want to do, or is there another approach typically used for this? I haven't yet found an example of how to create a time coordinate variable with calendar attribute all_leap or 366_day.

My concern is that I'll need to do something to account for the "filler" Feb 29th in the non-leap years in order to satisfy software such as Panoply which I use for quick plots when doing data analysis. I'm not referring to the data variable values, I mean the actual time step values such as "5894 days since 1900". For example when I'm stepping through the data timestep by timestep (day by day) I want to make sure that I don't start getting off-by-one errors that end up confusing Panoply, so when I'm looking at a plot for a timestep it's interpreted correctly when it displays the time value in date format.

Maybe the crux of this is whether or not I can have duplicate values in the array of time step values, and if so will Panoply etc. handle these gracefully, i.e. when I'm constructing an array of time values to load into the time coordinate can I duplicate the value for Feb 28th in the array element mapping to Feb 29th when it's not a leap year?

James Adams
  • 8,448
  • 21
  • 89
  • 148

1 Answers1

0

This a tricky issue, which comes up when computing daily climatologies over many years. You want your computations to include 366 days even for non-leap years but to use NaN for Feb. 29.

You don't mention what language you are using to create your NetCDF files. There is an answer using Python and Pandas, in the context of creating climatologies at this question: Compute daily climatology using pandas python which might help get you started.

My answer to that question shows a method for dealing with the leap year issue.

I've created 30 year daily climatology files, using this method and Panoply has no problems viewing them.

Eric Bridger
  • 3,751
  • 1
  • 19
  • 34
  • Thanks, Eric. This will be interesting once I'm past my current quandary of how to construct the array of time values to assign into the NetCDF time coordinate variable when using a calendar attribute of '366_day'. I'll update my question to be more clear about what I've tried so far. And it may be that doing things this way using a 366_day calendar to store daily data in the NetCDF may be more trouble than doing things the normal way and manipulating the daily data into regular 366 day years after I read it from the NetCDF. – James Adams Mar 11 '18 at 15:28
  • Eric are you writing NetCDF using a time coordinate with its calendar attribute set to `366_day` or `all_leap`? If so can you point me to the code that writes the file? I can't find an example of how this should be done, it seems to be an uncommon use case. – James Adams Mar 11 '18 at 15:35
  • 1
    No. I'm just temporarily grouping the data by day of the year, assuming all years are leap years, 366 days. The output is just a regular time series using proleptic_gregorian calendar. I wasn't even aware of the 366_day calendar. But it looks like you'd lose a true time stamp, i.e. lose any specific year values. – Eric Bridger Mar 12 '18 at 16:43
  • This is what I'm doing now as well, I gave up on trying to use a 366_day calendar attribute in my input or output NetCDF files, and instead using a normal gregorian calendar. That was a real waste of time... – James Adams Mar 13 '18 at 02:56