zlacker

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...

>>kevmo3+(OP)
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.

>>kevmo3+(OP)
It seems that your JSON file is way larger than it could be. The current JSON gzips into 140 KB, but there are only 45K quad labels and 32K leaves (where about a half of them are references). And all references are sorted in order so you can use delta coding at some point. So we can safely assume that references are no more than 2 bytes while direct tz indices are almost likely one byte and we should expect about 60 KB instead. Of course you need an additional jump table in order to avoid linear scanning, but that table is only required at higher levels so it is negligible in comparison.