One solution would be to change the error raised here to a warning, and continue to instantiate the object using datetime.now()
In theory, the GitHub action above should work when run via its cron schedule. However, the awkward hack around daylight savings time leaves a few days a year of incorrect US Eastern/UTC differences.
Definition of done
The list below includes another date-related CladeTime validation change that @elray1 and I have discussed recently.
[ ] If no tree_as_of parameter is specified when instantiating CladeTime, tree_as_of should default to the sequence_as_of value.
[ ] If either tree_as_of or sequence_as_of is a future date, CladeTime instantiation should give a warning and use the current datetime value instead.
Background
Instantiating
CladeTime
currently throws an error if you pass asequence_as_of
date that is in the future.This seemed like a good idea at the time, but that behavior makes it hard to test scenarios like a GitHub action that wants to instantiate based on a round close date.
One solution would be to change the error raised here to a warning, and continue to instantiate the object using
datetime.now()
In theory, the GitHub action above should work when run via its cron schedule. However, the awkward hack around daylight savings time leaves a few days a year of incorrect US Eastern/UTC differences.
Definition of done
The list below includes another date-related CladeTime validation change that @elray1 and I have discussed recently.
tree_as_of
parameter is specified when instantiatingCladeTime
,tree_as_of
should default to thesequence_as_of
value.tree_as_of
orsequence_as_of
is a future date,CladeTime
instantiation should give a warning and use the current datetime value instead.