Fix timezone calculation for non-integer timezones #236
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
The changes look good for me. But as I'm not working with python regularly maybe some else could have a look |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
There are two places in the code which apply a timezone difference to a parsed date: when parsing command line arguments (
Configuration._set_date) and when processing a hit (Parser.parse). They do that in a rather hacky way: the timezone is parsed as a number and then the difference is set to benumber / 100hours.This kind of works... except it assumes that timezones can only be at full integer intervals, and that's not true. There are several non-integer timezones, including in such important countries as India (+05:30) or Iran (+03:30). In that case,
"0530"is interpreted as 5.3 hours ahead of UTC instead of 5.5...For example, with such log line:
1.2.3.4 - - [29/Nov/2018:15:30:00 +0530] "GET / HTTP/1.1" 200 6355 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0" 0.014the 15:30 Indian Standard Time should be read as 10:00 UTC (11:00 CET). Instead, it's 11:12:
This PR makes a relatively small fix to the timezone calculating logic in that the parsed "number" (not really an actual number) e.g.
530is divided into hours and minutes separately using integer division and modulo and passed todatetime.timedeltaas separate parameters. With that change, the timestamp is parsed as 10:00 UTC (11:00 CET) correctly: