pvlib.iotools.get_cams not following CAMS default timestamp convention

[ramaroesilva]

Describe the bug
pvlib.iotools.get_cams (link) provides satellite radiation estimates at different temporal scales (from 1 min to 1month). while the function allows users to define their timestamp convention through the labelparameter (i.e., if 15-min averaged datapoint at 10:00 corresponds to 9:45-10 or 10-10:45), the default assumption is not coherent with the data provider original setup.

Expected behavior
label would be right by default, rather than left.

Screenshots
From CAMS documentation:

[adriesse]

It seems ok to return data with a different default convention than cams (iotools convention?) as long as they line up correctly... do they?

[ramaroesilva]

It's not a "capital sin", but I've understood from previous discussion that pvlib aims to mimic as much as possible the original source. In addition, from my understanding (but I'm biased and with only a partial perspective, naturally) the right option is much more in agreement with conventions.

If there is a general feeling that there is no need to adapt the code, I would at least clarify this in the documentation.

[AdamRJensen]

The SoDa api returns a dataset where the first column is called "Observation period" and is in the format "start/end". An example entry is: 2025-01-01T00:00:00.0/2025-01-01T00:15:00.0.

Since both the start and end time is returned, pvlib has to make a choice of which to use. The choice of 'left' was made since this is the default when resampling data using pandas. This is well documented in the parameter label

After a quick investigation, I see that the CAMS data from ADS (which is in netcdf files) labels the time stamps by the end of the interval. I suppose this is what you were referring to.

In the future, I hope that pvlib can adopt a new parameter for the iotools called index, which would make use of panda's interval index and would allow users to specify either left, right, mid, or interval. The get_meteonorm function currently has a version of this implemented, which allows returning an interval index.

[adriesse]

Does using interval indexes work with the (many) functions that are expecting a date-time index?

[cwhanse]

Not advocating for any of these alternatives to IntervalIndex, just tossing them out:

• add an alignment kwarg that defaults to None (return data as aligned by the source), set to left to shift data (as necessary) to be left-aligned, etc.
• add left-alignment when map_variables is True

Both of these idea risk introducing some confusion if a user is comparing what pvlib.iotools returns with some other view of the source data.