bmi.get_current_time and bmi.get_end_time are broken.

[BSchilperoort]

Wflow version checks

• I have checked that this issue has not already been reported.

• I have checked that this bug exists on the latest version of Wflow.

Reproducible Example

After bmi model initialization:

BMI.get_current_time(model)
BMI.get_end_time(model)

Current behaviour

Gives MethodError: no method matching value -(::String) (or similar)

Desired behaviour

Gives the end/current time.

Additional Context

The subtractions don't work because model.config.starttime and model.config.endtime are strings:

function BMI.get_current_time(model::Model)
    0.001 * Dates.value(model.clock.time - model.config.starttime)
end

function BMI.get_end_time(model::Model)
    0.001 * Dates.value(model.config.endtime - model.config.starttime)
end

[verseve]

Hi, I cannot reproduce this issue, it is also part of the tests, see for example test/bmi.j. Could you perhaps provide a bit more info on how this was tested? model.config.starttime and model.config.endtime are not string but DateTime types.

[BSchilperoort]

I think it has to do with the specific config file I am using. This is the start of the config for the Humber case that Tycho Bovenschen provided us:

casename = "wflow_sbm"
calendar = "proleptic_gregorian"
starttime = "2013-11-25T00:00:00"
endtime = "2013-12-15T00:00:00"
time_units = "days since 1900-01-01 00:00:00"
timestepsecs = 3600

While the moselle sbm example has the following:

calendar = "proleptic_gregorian"
endtime = 2000-02-01T00:00:00
starttime = 2000-01-02T00:00:00
time_units = "days since 1900-01-01 00:00:00"
timestepsecs = 86400

The top configuration loads fine, and updates fine. However, the BMI functions do not work due to the misconfiguration.
So I guess the problem is not in the BMI, but in the config parsing.

[visr]

Yeah TOML has datetime support. If that is used it is working fine. But Wflow also accepts strings here, which are converted to datetime, though not in these BMI functions.