2. Similarly to above, how do we handle yearly forecasts in a non noleap calendar? Currently the practice is to use YS similar to MS above.

import cftime
import xarray as xr

inits = xr.cftime_range('1994', '1996', freq='YS')
inits = xr.CFTimeIndex(inits)
print(inits)
>>> CFTimeIndex([1994-01-01 00:00:00, 1995-01-01 00:00:00, 1996-01-01 00:00:00], dtype='object')

# Align with verification for next year.
inits.shift(1, 'YS')  # Current way we handle it 
>>> CFTimeIndex([1995-01-01 00:00:00, 1996-01-01 00:00:00, 1997-01-01 00:00:00], dtype='object')

# Initialization on a specific day with year forecasts.
inits = [cftime.DatetimeProlepticGregorian(1995, 3, 1),
         cftime.DatetimeProlepticGregorian(1996, 3, 1)]
inits = xr.CFTimeIndex(inits)
print(inits)
>>> CFTimeIndex([1995-03-01 00:00:00, 1996-03-01 00:00:00], dtype='object')
inits.shift(365, 'D')  # Perhaps their verification is aligned one year out.
>>> CFTimeIndex([1996-02-29 00:00:00, 1997-03-01 00:00:00], dtype='object')

Similarly we use YS here to just assume that the 1995 average is written as '1995-01-01' in the verification product. Same issues as above here.

• How do we deal with time bounds?
• How do we deal with leap years? -- See the second example. Maybe they initialize Nov. 1st and want to align with the Nov 1st entry from the verification product. Using 365 gets out of sync here due to leap years (although I think we could just have a variable 365 or 366 addition depending on if it's a leap year and they're using a leap year calendar).

3. How do we deal with integer decimal time?

Currently, if an init coordinate comes in with integer or floats, we just assume that it's annual resolution initializations and convert to year-start for that integer.

E.g.

import numpy as np
import pandas as pd
from climpred.utils import convert_time_index

init = np.arange(1990, 1995)
da = xr.DataArray(np.random.rand(len(init)), dims='time', coords=[init])

print(convert_time_index(da, 'time', '').time.to_index())
>>> CFTimeIndex([1990-01-01 00:00:00, 1991-01-01 00:00:00, 1992-01-01 00:00:00,
                 1993-01-01 00:00:00, 1994-01-01 00:00:00],
                 dtype='object', name='time')

So here we just take floats/ints and essentially append on -01-01. But what if the values coming in are decimal time (e.g. 1990.3) or netcdf style integers that correspond to "days since ...". Should we have a try statement that tries to decode_cf on integer/float times? What if it comes in as 19950101 and could just be converted that way?

Alright that's all I've got for now! Just wanted to open the discussion with people who have thought about these things so we can find a standard and start chipping away at them with PRs.

Regarding 3.: is there any data center that provides fractional float inits? We could simply not allow this... easiest way.

I'm thinking these issues are big enough that it would be helpful to collect information from the various hindcast datasets currently out there and then see what is common and what is different between them and what is clearly defined and what is ambiguous wrt to handling of time and time-related metadata. I think this will help us see how to answer these questions robustly. At the very least, it will help me get a big picture view of the issues across the various communities and envision a robust set of solutions. Where is the best place to collect all this information?

Once we agree on a location, I can start populating information for NMME, SubX, International S2S database, and the NCEP/UFS hindcasts (with the idea that we keep weather timescales in mind for the future as well). I think we have the potential to help define a more common and consistent set of metadata and definitions across the entire Earth System Prediction community with respect to time. We are planning for the future for SubX and NMME databases so there is also an opportunity here to influence how they will be setup in the future.

I think having an overview of the different product names, eg. NMME, SubX, CESM-DPLE, MPI-ESM MiKlip, ... and the details and what this means in the context of climpred might be nice and more transparent for all users.
however, this would take same of effort for all of us to document.

#332 requires Leap or NoLeap. it cannot handle the other calendars yet. for now it checks dayofyear in resampling uninitialized.

This goal is worked at in https://github.com/bradyrx/climpred/pull/332 but not resolved.

a comment when implementing .plot():

need to align with discussion about init times: I propose:

• initialization: as the exact date of the start of the forecast
• observation/hist time: as the middle of time spanned
• lead: as ints but when converted to real time as middle of time