You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It would be convenient to store time durations directly in the DB rather than storing it as a number of seconds.
Describe the solution you'd like
Use a Python timedelta to map to the Comdb2 intervalds or intervaldsus values. This seems like a natural mapping.
Describe alternatives you've considered
The alternative is to use a double or an int (depending on the needed precision) to store the duration as a number of seconds.
The text was updated successfully, but these errors were encountered:
We have a good reason for not supporting intervalym, but I can't see a reason for not supporting intervalds and intervaldsus. They do match the semantics of Python's datetime.timedelta, as far as I can see.
The one tricky thing here is the type mapping - we'd need to figure out which of the two Comdb2 types should be mapped directly to datetime.timedelta, and we'd need to figure out what to do for the other one. I'm tempted to think that both should decode to a datetime.timedelta on reading, and that a datetime.timedelta should bind as a intervaldsus when bound as a parameter, but that would be inconsistent with how we handled datetimeus.
Is your feature request related to a problem? Please describe.
It would be convenient to store time durations directly in the DB rather than storing it as a number of seconds.
Describe the solution you'd like
Use a Python timedelta to map to the Comdb2 intervalds or intervaldsus values. This seems like a natural mapping.
Describe alternatives you've considered
The alternative is to use a double or an int (depending on the needed precision) to store the duration as a number of seconds.
The text was updated successfully, but these errors were encountered: