Bugfix #138 in write_forcing

[hboisgon]

Correct bug with forcing with cftime.DatetimeNoLeap

Problem was coming that if forcing timespan was shorter than intented wflow starttime and endtime (old missings flag), we would sel the forcing dataset:

hydromt_wflow/hydromt_wflow/wflow.py

Line 1982 in 04fad11

ds = ds.sel({"time": slice(start, end)})

The bug was here that start and end are pd.datetime and the slice does not work if ds.time is of type cftime.datetime. It can be fixed by converting start and end to strings first with start.strftime(format).
I don't really think we need the slicing though so I deleted it.

What I also found is that the starttime and endtime can have a different timestamp than the forcing (eg 2010-01-01 08:00:00 instead of 2010-01-01 00:00:00) so I added an extra check to correct the starttime and endtime to match better what is inside the forcing file

[hboisgon]

@Jaapel can you check that this solves your issue ?

[Jaapel]

@hboisgon I do not get the datetime error anymore 👍

[hboisgon]

Would be nice to test hydromt_wflow (and hydromt) with cftime data maybe when cmip6 from gcs is implemented.
While digging I found than in xarray.open_dataset there is a use_cftime flag which is None by default. This means that times will be decoded to np.datetime64[ns] where possible and else to cftime.datetime:
https://docs.xarray.dev/en/stable/generated/xarray.open_dataset.html

As these two objects are quite different in functionalities I wonder if we maybe should not be more strict in hydromt and maybe always use cftime? @DirkEilander what do you think?

[DirkEilander]

What are the different methods of the numpy datetime and cftime objects? I'm not sure if forcing all to be cftime will help or create more problems. Perhaps good to raise an issue in the core and investigate the benefits and limitations of both. If can easily accommodate for both that would be my preferred option.

[hboisgon]

I agree it's not optimal to change but still maybe worth a discussion in HydroMT so I'll open one there. In the meantime, could you review this PR?

[laurenebouaziz]

the workflow does not work for 360 days calendars.
when da.indexes['time'].calendar != "360_day" the .to_datetimeindex() does not work because of the presence of 29th of february each year:
*** ValueError: Cannot convert date 1970-02-29 00:00:00 to a date in the standard calendar. Reason: day is out of range for month.

Maybe good to further discuss how we want to deal with this.

[laurenebouaziz]

discussed with @hboisgon that we only correct dates in toml for standard calendars. see 0b3f977