Bug description
We were struggling quite a lot with how to handle the period startdates of the projectfile in python, given that the years entered are usually outside the nanosecond range. We resorted to just ignoring the year that is entered, and replacing it with 1899, which is outside iMOD5's calendar range, so doesn't result in conflicts with regular transient packages.
However, this is not how iMOD5 treats period startdates, from the manual:
Startdate of the given period. A PERIOD repeats until another time
definition is more close to the current timestep. Specify the date as
dd-mm-yyyyhh:mm:ss, so to specify midnight for the 6th of September
it needs to be entered as: 06-09-2018 00:00:00. If this need to applied
each year the notation is 06-09-0000 00:00:00 which means that it applies
for the 6th of September no matter what year. Another example for
a repition per 6 hours is 00-00-0000 06:00:00, in this case for each day,
from 6am this packages applies.
I don't think we need to support the per 6 hour stuff, as I've never seen this in the wild. However, supporting the year 0000 needs to be done. Unfortunately, datetime.strptime() doesn't support the year 0, at minimum it requires the year 1, which is quite surprising.
Furthermore, in the iMOD importer, I only support a hardcoded "summer" and "winter" period label, however, I've seen this being used in IBRAHYM:
Periods
winter1
01-01-0000 00:00:00
summer
01-04-0000 00:00:00
winter2
01-10-0000 00:00:00
Apparently, iMOD5 doesn't properly forward winter2, so they created this workaround. Not sure whether we should support this, it can increase code complexity quite a lot. At least we should document this as a Known issue.
Bug description
We were struggling quite a lot with how to handle the period startdates of the projectfile in python, given that the years entered are usually outside the nanosecond range. We resorted to just ignoring the year that is entered, and replacing it with 1899, which is outside iMOD5's calendar range, so doesn't result in conflicts with regular transient packages.
However, this is not how iMOD5 treats period startdates, from the manual:
I don't think we need to support the per 6 hour stuff, as I've never seen this in the wild. However, supporting the year 0000 needs to be done. Unfortunately,
datetime.strptime()doesn't support the year 0, at minimum it requires the year 1, which is quite surprising.Furthermore, in the iMOD importer, I only support a hardcoded "summer" and "winter" period label, however, I've seen this being used in IBRAHYM:
Apparently, iMOD5 doesn't properly forward winter2, so they created this workaround. Not sure whether we should support this, it can increase code complexity quite a lot. At least we should document this as a Known issue.