Support time points as numeric indexes #240
Draft
+392
−7
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is a rough draft
What's is implemented:
datetime.datetimeworks as numeric index.datetime.dateworks as numeric index.datetime.timeworks as numeric index.(very sketchy, see below)What can be added / improved:
datetime.timecustom parsing implementationdatetime.timebecause user will have to write parsing(validation) themselves otherwise(seepost_model_timein tests).datetime.timedelta(I skipped it for now).Model.find(Model.field < "Thu Sep 25 10:36:28 2003")or ISO format, or etc...Questions:
Right now I just convert everything to UTC before saving. (This needs to be checked)
Model.find(Model.field < "Thu Sep 25 10:36:28 2003")or"2003-09-25T10:49:41.5-03:00"or any other string in expressions. (Becausepydanticsupports only ISO format(I think)). We could usedateutil. Or make it optional dependency.pydanticparsing support parsingdatetimefrom integers ms out of the box.redis-om-node, and there they support precision to seconds(I'm not sure): https://github.com/redis/redis-om-node#searching-on-datesModel.datetime < date/time). Should we support this? Or catch this and raise exception?Problems:
, very custom logic(probably wrong)Sketchy things:
datetime.time custom parsing implementationresolve_value. Maybe there is better approach.Fixes #199