[tz] Reason for removal of several TZ abbreviations

[Brian Inglis]

On 2017-12-05 14:29, Guy Harris wrote:
> On Dec 5, 2017, at 12:35 PM, Brian Inglis <Brian.Inglis at systematicsw.ab.ca> wrote:
>> Not hard to put together a script using a "what is my external IP address"
>> script that accesses an external web server to return your system's public
>> address, geoiplookup, and tzselect -n 1 -c latlong, although YMMV.
> That's a start, but if it determines you're in San Simon, Arizona:
> 	https://en.wikipedia.org/wiki/San_Simon,_Arizona
> it gets it wrong:
> 	$ ksh ./tzselect.ksh -n 1 -c +3216-10913
> 	Please identify a location so that time zone rules can be set correctly.
> 	Please select one of the following time zone regions,
> 	listed roughly in increasing order of distance from +3216-10913.
> 	1) Mexico - Mountain Standard Time - Sonora
> 	#? 
> So, for doing a script to do the equivalent of what macOS and iOS do, you'd
> want more like "get your external IP address, geolocate it, and hand it to a
> program with a set of shapefiles for tzdb regions". See, for example
> 	https://github.com/evansiroky/timezone-boundary-builder
> (to which
> 	http://efele.net/maps/tz/world/
> now refers people).

More likely query the underlying geodatabase for the time zone region, often
indexed by the minimum bounding rectangle [min x, min y[ - [max x, max y]
surrounding the possibly non-convex hull, then resolve muiltiple hits by
checking the interior convex polygons contain the coordinate, or equivalent tests.

There may still be a problem if the coordinate lies *on* a boundary line, which
could be resolved by finding the (largest) nearest populated settlement in the
geodatabase, and using those coordinates for the query.

The query could also be restated as finding the time zone of the (largest)
nearest populated settlement to the coordinates,

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada