but it didn’t work because the output did NOT contain a time zone.
Where would I find documentation for the “reverse”? I don’t know what other formats there are beside JSON, or what addressdetails`` means. Or whether zoom is important.
(Or why the post formatting above is so weird)
The location happened to be (in this case) less than a meter from a bar in Oregon: i.e., lat=44.061755&lon=-123.018836
Actually, I have located the documentation at Reverse - Nominatim Manual but if anyone has a quick answer, I would not complain. :-) There is no mention of timezone in that documentation.
(no idea about geocoding, bit) perhaps edit your post to use code indentation - put four spaces at the beginning of every line you want handled that way.
I don’t think the Nominatim reverse geocoding output returns the time zone. Your question was asked on the old help site, maybe try and see if any of the solutions suggested there still work:
I’m looking at that TimeZone perl module now. It also has “gaps” in the documentation, but it seems like it will do what I want once I figure out all the missing details.
That (old help) has half of the solution, but that half (and the other half) have incomplete documentation.
I consulted two LLMs that were hopeless. perplexity.ai took quite a bit of coaxing to come up with something that looked reasonable until (after installing a zillion perl modules), I found that the suggested nominatum/reverse is NOT part of the answer.
I think that’s what’s called “a learning experience” …
LLMs are fantastically useful for some things (for example where a library is used in all sorts of different places and different ways, and the documentation is “suboptimal”), but less so in others. Nominatim’s documentation is actually pretty good, and discussion around it tends to occur in a relatively small number of easily human-searchable places (the OSM software world is pretty small). It’s unfortunately easy for an LLM to “make things up” in a way that is completely plausible, even to someone familiar with the subject. Any time something suggests “a zillion perl modules” it’s worth taking a step back and trying to break down the problem a bit.
The LLM didn’t suggest a zillion perl modules, but in order to stop getting missing dependency messages from what it did suggest, …
I am well aware of their propensity to invent things, so when it comes to code, I always give an eyeball review and if that passes, careful non-destructive testing. For other things, I only use services that provide sources, which I always check. One episode, the LLM gave five sources. The “answer” was a plagiarism of one of the sources, and the other four were completely unrelated.
Apparently not easy enough for me to figure out. There’s a perl library that allegedly can take zulu time, lat, lon, and timezone, and convert the Zulu time to the other time zone. But the other perl library that is supposed to provide time zone from lat/lon offers a sample usage script that returns nothing.
After a major struggle with Claude Haiku, I got a script to work on GPX files.
The LLM used the word “robust” nine times when “my mistake; try this” would have been more appropriate.
About halfway through, I said “I wish one of us actually had Python experience.”
But it finally works. Modifying it top work on image files shouldn’t be difficult—replace the three lines that call “exiftool | grep | awk”
The zsh/Python script is a mess but it works. If anyone cares, a copy is at https://HappyHobo.net/Local_Time_GPX
Correction: it does not work. The Python part computes local time as expected, but it fails to feed it back to the shell.
evansiroky/timezone-boundary-builder (MIT-licensed code, data based on OSM) may meet your needs. Lots of options and APIs for over a dozen programming languages.
Has the LLM suggested that you first decide whether you want an online solution, or offline?
You can either query OSM over the internet (as you were doing with the Nominatim query you mentioned in the first post), or you can use some sort of library that has a pre-computed set of timezone boundaries and checks those without needing to make an HTTP request.
Those are very different approaches.
But by its nature, the LLM wants to give you an answer, not design questions to answer…
My script now works for GPX files. Just needed better ways of getting zsh variables into and out of Python.
But I’ll probably look at the other ideas.
My first approach used evansiroky/timezone-boundary-builder to make a local DB but the code thzt was supposed to use that DB to get the time zone for a given lat/long consistently returned nothing.
…