-
Notifications
You must be signed in to change notification settings - Fork 22
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
DateIndex._convert(): special calculation of timestamp value #123
Comments
I don't know why the standard libraries were not used. Maybe there was a 2037 issue in previous python or unix (32bit) versions. At least the time unit of t_val is minutes and the type of the variable is not signed integer. I.e. your code should be like this
The value is also missing the minutes that have passed until 1970. Once the code should be changed, the result of the new method is not the same of the old method. Maybe tests must be rewritten and all datetime indexes of running systems with datetime indexes must be rebuilt. |
Sorry, the old code Py code snippet for testing
Check Timestaps: https://www.confirado.de/tools/timestamp-umrechner.html |
drfho wrote at 2021-7-9 04:18 -0700:
Sorry, the old code `((((yr * 12 + mo) * 31 + dy) * 24 + hr) * 60 + mn)` seems not to compute minutes.
It does not need to: the indexed value is (in principle)
an implementation detail. It can be computed any way so long
as the computation ensures that all equivalent allowed input values
are mapped to the same indexed value and that the computation
happens identically on indexing and searching.
When I remember right, then a `DateIndex` wanted a reduced resolution
(to make the index less bushy/broad for better efficiency).
A resolution in the order of minutes was apparently chosen
(which is far coarser than that of unit time stamps).
With some modulo computations, you can easily
reconstruct "yr", "mo", "dy", "hr" and "mn" from
the indexed value (as computed above).
|
Hello,
the timestamp calculation in
https://github.com/zopefoundation/Products.ZCatalog/blob/master/src/Products/PluginIndexes/DateIndex/DateIndex.py#L141
looks somehow surprising: is there a special reason for e.g. "yr*12"?
In my opion a unix timestamp may be more adequate for the job, because its easier to process the timestamps back into a valid datetime value.
Or is there any special reason to use that "internal" timestamp format and not a standard unix value for the zcatalog-index?
Any hint is welcome,
looking forward
fh
The text was updated successfully, but these errors were encountered: