-
Notifications
You must be signed in to change notification settings - Fork 106
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
Fractional deltas result in incoherent results. #100
Comments
I'm surprised it worked at all to be honest :) The issue is that the bit of code that converts the "2.7 months" into a quantity (2.7) and unit (months) is a regex that probably doesn't understand anything other than integers. The evalModifier code will first pull off "ago" and then send "2.7 months" to be evaluated. But 2.7 is caught by the RE_NUMBER regex and mangled because it assumes an integer. So yea, the assumption at line 978 or so of init.py that the quanity will only ever be an integer probably needs to be fixed. The RE_NUMBER regex assumes word boundaries:
that's the \b part of the above - that would have to change to also include the locale's decimal character (. or ,) but that could also brings in other edge cases. |
Fortunately the word boundaries only affect written numbers like "one" and "two" so just the righthand side would need to be tweaked. Similar to what is done for seconds (
with the first still matching numbers as words, the second matching numbers with optional decimals like 4 0.3 and 4.34, and the third matching decimals with no preceding number like .25. Not sure what might be needed to handle the match but that should take care of the regex. Locale-aware separators would be nice in case people decide to use thousands separators like 1.000,50 but probably not a common problem. |
I didn't expect it to work, but I'm surprised even the sign was so wrong. If I have no idea where the days component is coming from at all. |
I think I have fixed this problem in my latest pull-request (#111). But to be honest the delta of |
I'm going to close this because it sounds like it's been fixed. |
I'm working with a lot of "human readable" delta times, e.g. "5.1 hours ago".
The sensibility of fractional hour representation aside, parsing strings like that seems to lead to inconsistent, and frankly odd results a lot of the time.
Here is a set of test examples for this:
Where each line is a tuple:
("Ago:", {instr}, {parsed_time}, {datetime.datetime.now()-parsed_time}, {Pretty-Printed datetime.datetime.now()-parsed_time}, {result_type})
.I'll probably have a poke at looking about inside the library this weekend, but frankly I have NO idea how /any/ of the dates are somehow winding up in the future, when the input string clearly has "ago" in it.
For that matter, the fractional months ago ('2.7 months ago') is somehow being parsed as 1 day, 23 hours and 53 minutes in the future.
The text was updated successfully, but these errors were encountered: