Hey, it's always good to see your PRs! I hope you're doing well.

Actually there's a related issue discussed in #326. I even think these two might be resolved at once.

As for the /timezone method, I don't think that it should be combined with the reverse method, because the returned data is semantically different. The plain reverse is intended to return a full address of the point, while the timezone is a different thing. In fact, GoogleV3 implements a similar functionality, so I think it could be used as an example here:

As for the /findNearby method, discussed in #326, well, I see at least two possible ways to implement it:

1. As a new single choice-like (or a boolean?) parameter for the reverse method,
2. As a new distinct method in the Geocoder class.

The first approach might look confusing (especially given that the two API methods, being called by the same single reverse function, have different sets of parameters), but it would allow to use the new API method with the other libraries/frameworks which assume that reverse geocoding can be done only one way (I suppose geopandas behaves this way).

The second approach might look cleaner from the geocoder's interface point of view, although it may still be confusing that a geocoder provides two distinct methods both doing reverse geocoding (it is confusing to me why geoname does actually provide so many different methods which could just be parameters for a single reverse method).

I haven't made up my mind yet on which way to go there, I would be glad to hear your thoughts on this one. I tend to incline towards the first option, yet I'm not certain about it. But anyway, this is out of the scope of the issue you're trying to resolve with this PR, so you may leave this out and work specifically on the timezone method instead.

Hi again, sorry for the wait, I've been really busy lately.
I have a question for timezone. Is it okay to do it like this, because api supports some additional optional keys such as radius lang date, but if we will return pytz object they're useless.
For example here what it can return with a request like this:
http://api.geonames.org/timezoneJSON?lat=47.01&lng=10.2&radius=10&lang=ru&date=2018-01-01&username=demo

{"sunrise":"2018-10-18 07:40","lng":10.2,"countryCode":"AT","gmtOffset":1,"rawOffset":1,"sunset":"2018-10-18 18:27","timezoneId":"Europe/Vienna","dstOffset":2,"dates":[{"date":"2018-01-01","sunrise":"2018-01-01 08:05","sunset":"2018-01-01 16:40"}],"countryName":"Австрия","time":"2018-10-18 18:12","lat":47.01}

Same goes for findNearby, but I think it doesn't matter that much or does it?

This is a great question regarding the other data returned by the timezone endpoint. I see the following options:

1. Return a custom wrapper instead of pytz.timezone, something similar to Location, which contains a raw attribute.
2. Move the actual implementation of the timezone method to another one, and make the pytz timezone construction in the current one, so the raw data could be retrieved by calling the second method.

I tend to incline towards the first option, but it would create inconsistency with the Google's timezone method.

I suggest you to just keep the pytz timezone for now. I'll reason about it before the release and will probably introduce the custom wrapper.

@Svalee I have just merged #332 which adds the aforementioned timezone wrapper. Could you please rebase your branch on top of the current master and use that wrapper in this PR?

Hey @Svalee, do you think you could work on this before I'd cut the next 1.18 release? If not I'd be happy to take this over so this feature could be finally published. :)

@KostyaEsmukov hey, yeah, I am very sorry about this, when is 1.18 release?
I'll work on this today and tomorrow if I wouldn't be able to do it today, is this fine?

when is 1.18 release?

This PR is the main blocker, so as soon as it is merged.

I'll work on this today and tomorrow if I wouldn't be able to do it today, is this fine?

Don't worry, it was just a friendly reminder from my side. This is fine. :)