Running simulations for locations in the southern hemisphere

[gsrohde]

Looking at the module thermal_time_and_frost_senescence, I noticed that this module accommodates (or tries to accomodate) locations in the southern hemisphere. But how would weather data for such a location be presented? Presumably the growing season would span years. But the year column is ignored by all modules except solar_position_michalsky. Presumably the row after doy = 365, hour = 23 would have doy = 1, hour = 0 and the corresponding times would be computed as 365.958333 and 1.000000. This will obviously cause problems.

[leavesandlemmas]

Maybe the most elegant fix would be to use a datetime object (like POSIXct in R + some c++ equivalent) to parse the timestamp and do all of the conversions between different representations. That way the weather data would only need a single column / variable containing the year, day, and time (and timezone).

Alternatively, we could have the fractional_doy "time" be modulo 365 so that 366 = 1 mod 365. The DOY / hour aren't really used by modules other than solar_position_michalsky ( except for those with a sowing_time) so it wouldn't really create any problems right?

[gsrohde]

Maybe the most elegant fix would be to use a datetime object (like POSIXct in R + some c++ equivalent) to parse the timestamp and do all of the conversions between different representations.

This certainly would be an improvement over the somewhat ambiguous time column that gets added.

That way the weather data would only need a single column / variable containing the year, day, and time (and timezone).

I'm fairly sure that whatever source we use for weather data gives rise to the doy and hour columns that it always includes. Nevertheless, we could still have the code add a column of datetime objects rather than adding the time column, as it does currently.

Alternatively, we could have the fractional_doy "time" be modulo 365 so that 366 = 1 mod 365. The DOY / hour aren't really used by modules other than solar_position_michalsky ( except for those with a sowing_time) so it wouldn't really create any problems right?

solar_position_michalsky could be changed to take datetime inputs.