Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support intervalds and/or intervaldsus #36

Open
eo2020 opened this issue Jul 28, 2022 · 1 comment
Open

Support intervalds and/or intervaldsus #36

eo2020 opened this issue Jul 28, 2022 · 1 comment

Comments

@eo2020
Copy link

eo2020 commented Jul 28, 2022

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.

@godlygeek
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants