As mentioned in the question comments, one can find options (including offline approaches) to resolving a latitude and longitude to an IANA time zone entry in this answer.
With regard to your second question, all changes to time zones in a given region are already represented in the IANA time zone database via its Zone and Rule entries. This includes daylight saving adjustments, changes in standard offset, and changes in the English abbreviation for the name of that time zone (when one is applicable).
In the case you described in the question comments, the entirety of time in Crimea is represented by the Europe/Simferopol zone and its associated rules. You can review the details here. It includes the 2014 changes you mention.
If actually you have knowledge of some areas of Crimea whose local time differed from Simferopol, then you should submit that to the tz mailing list for discussion and debate.
In such cases, if verified and warranted, a "zone split" would occur. This results in the creation of a new IANA time zone identifier, using the most populous city in the region whose time differs from the existing region. When a new zone is created, the existing history is copied over from the previous zone. Only the LMT entry is adjusted to reflect the new location. Then either the new or old zone has the deviation applied, depending on which side has the change. A example would be in release 2018h when Asia/Qostanay was created, splitting away from Asia/Qyzylorda (both in Kazakhstan).
There are very few scenarios where the IANA TZDB doesn't cover changes in time zones in the way you are suggesting:
- The deviation occurs only for dates prior to 1970.
- If boundaries between regions are fluid, such as during a war or insurrection.
- The accuracy of the information regarding the deviation is not verifiable or it is significantly disputed.
- The deviation occurs in a region that is too small to warrant tracking its changes, such as small settlements or individual persons living in rural areas along borders.
Such things are described further in Theory and pragmatics of the tz code and data (the theory.html file in the TZDB). They are sometimes discussed and debated on the tz mailing list as well.
Lastly, keep in mind that the IANA TZDB doesn't actually try to define geopolitical borders. Such things are often disputed, and are more in the realm of map makers than time keepers. Thus, the lat/lon lookup is only as good as the map behind it. In most of the open source solutions offered in the list I referenced earlier, the boundaries are based on the data from Time Zone Boundary Builder project, which in turn uses Open Street Map (OSM) for most of its geopolitical boundaries. However, the online web services offered by Google, Microsoft, and others don't necessarily use that same map. Thus, it is possible for the same latitude and longitude to resolve to a different IANA time zone identifier depending on which data source you use.
