On Tue, 20 Aug 2013, Paul Eggert wrote:
+ -c COORD + Instead of asking for continent and then country and then city, + ask for selection from time zones whose largest cities + are closest to the location with geographical coordinates COORD. + COORD should use ISO 6709 notation, for example, '-c +4852+00220' + for Paris.
Thank you, this looks useful. However, I believe that ISO 6709 allows several variations, including: degrees only (e.g. +49+002); ... with decimal degrees (e.g. +48.85+002.35); degrees and minutes (e.g. +4851+00221); ... with decimal minutes (e.g. +4851.40+00221.05); degrees, minutes, and seconds (e.g. +485124+0022103); ... with decimal seconds (e.g. +485124.1+0022103.2); The awk code can't handle the integer degrees form, but it can handle degrees and decimal degrees. When I attempt to use integer degrees, it seems to treat it as minutes instead of degrees (try "+49+002" and it will suggest some time zones in Africa instead of in Europe, but try "+49.0+002.0" and it works). I think the code should count the digits to figure out whether the integer part is in degrees (DD or DDD), degrees and minutes (DDMM or DDDMM), or degrees, minutes and seconds (DDMMSS or DDDMMSS). Alternatively, it could accept only a subset of the possible variations, provided that is clearly documented. I believe that ISO 6709 requires exactly two digits for the degrees part of the latitude, exactly three digits for the degrees part of the longitude, and exactly two digits for any non-fractional minutes or seconds. The awk code seems to relax this, especially where there is a decimal point, and I think that's useful for the integer degrees case and the degrees with decimal degrees case (e.g. to allow "+49+2" or "+48.9+2.3" instead of "+49+002" or "+48.9+002.3"), but dangerous for cases that involve minutes or seconds, because counting the digits is necessary to disambiguate those cases. Whatever you do, I think it needs a few more examples of coordinates in different formats. --apb (Alan Barrett)