Closed dasbiswajit closed 4 years ago
I am the author. I certainly don't like to hear that there are errors with major cities. (Did you mean Brasilia? Or all of Brazil?) Unfortunately I don't have time to do any debugging of this project. I'd therefore like to find a volunteer to take care of this stuff.
The bug is in one of these 3 areas:
When I was developing this, I had some methods to look up certain lat/lng's in the unprocessed input data, to diagnose which of these areas the error is in. Those methods are probably still in there.
Any takers?
Also note that you can try previous versions of the source files...some might be more accurate than others.
@drtimcooper Thanks for your support. Apologies If I hart you. This is one of the best library I have been using for last 5 years for my project. yes as of now the mainly 2 country users groups Brazil and Istanbul. Details below.
UTC - 2
actually it should be
UTC-3
UTC + 2
Actual it is
UTC +3
Good to know the error rate is low. And it's good to hear that people like it!
Are you volunteering to debug the project? If the error is in point 1 of my list above (i.e. a data error) then the complexity is low - either hack the input data or report it to whoever maintains this file. If the error is in point 2 then the complexity is high. I don't know how good you are at algorithms but you'd need to be good to fix it if it's an error in the main pipeline.
I have tested the TimezoneMapper class for the following coordinates -23.537646, -46.629636 and it returned "America/Sao_Paulo" timezone. It doesn't return the UTC offset. Converting the timezone string to UTC offset is in fact a totally different problem because it has a lot to do with DST in that region. When you get the TimeZone instance in Java, you have to give a date and dependent of that date value it sometimes return an instance with UTC + X and sometimes it is UTC + X +/- 1.
Absolutely right. Thanks a ton mate. I found the problem was with UTC converter library. Closing the issue.
For eg - Istanbul, Brazil etc.