zlacker

[return to "Show HN: A Simple Server to Match Long/Lat to a TimeZone"]
1. kevmo3+f2[view] [source] 2025-05-20 22:00:55
>>ChrisM+(OP)
Since the geojson for the timezone data is a static file you can avoid using a database entirely and ship it to your app.

If you'd like to avoid shipping a giant geojson, with the generosity of CDN providers you can actually hit the npm-hosting servers with HTTP Range requests and do this completely on demand from the client: https://github.com/kevmo314/browser-geo-tz

◧◩
2. edoceo+78[view] [source] 2025-05-20 22:52:40
>>kevmo3+f2
How should we get right bits by range? Wouldn't we get chunks of JSON that aren't delimited nicely?
◧◩◪
3. kevmo3+T8[view] [source] 2025-05-20 23:00:40
>>edoceo+78
Good question, the geojson data is actually broken down into two parts, a true JSON file and a quad tree: https://github.com/evansiroky/node-geo-tz/tree/master/data

So I guess it's a bit of a lie that it's only geojson :)

The way it works is you load the index file which contains the large regions (in other words, the first level or two of the quad tree) and if the time zone can't be resolved, it relies on querying the data file which is actually a multi-record protobuf file so you can load the specific range of data you're looking for. The algorithm is here: https://github.com/evansiroky/node-geo-tz/blob/master/src/fi...

Here's the step that resolves individual tree nodes: https://github.com/kevmo314/browser-geo-tz/blob/main/src/fin...

◧◩◪◨
4. edoceo+Ri[view] [source] 2025-05-21 01:04:57
>>kevmo3+T8
Ack. Like so many managers I asked the question before code review. I see the curTz and getting offset bytes for a proper blob decode. Very legal and very cool.
[go to top]