zlacker

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

>>kevmo3+f2
How should we get right bits by range? Wouldn't we get chunks of JSON that aren't delimited nicely?

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

>>kevmo3+T8
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.