timezonefinder vs timezonefinderL

I am trying to understand the implications of using one vs the other, and have a few questions:

1. With memory mode = false, wouldn’t using timezonefinderL be equivalent to using timezonefinder’s timezone_at, in terms of speed and memory load? Since that function supposedly uses only shortcuts, same as timezonefinderL.

2. Wouldn’t it be possible to provide a “limited” memory mode that only loads shortcuts for timezonefinder, to get the best of both world: fast lookups in most cases, and the option to do a deeper lookup when the tz returned is None.

[jannikmi]

thanks for the valuable feedback and suggestions. I’ll work on this as soon as possible.

TODO:

• add option to only load shortcuts
• load shortcuts into memory by default, introduction of flag?
• timezonefinder L deprecate

[zedrdave]

Regarding my use case (but I think the above feature would be beneficial to most users regardless of use case): I need TZ data for map points mainly located on sea (used in mapping routes for boats).

In terms of speed/memory/disk use/accuracy trade-off, I would say my ideal workflow (and what I would suggest to implement as a sensible default for the package) would be:

1. Full binary files that include oceans (considering the fairly low disk/RAM gain from excluding them)

2. Shortcut files with perhaps a bit more precision (eg doubled): still a much smaller RAM footprint over the full polygon files, with a much better chance of hitting a shortcut without needing polygons (especially in ocean areas, where timezone areas tend to be much straighter)

3. Only shortcut files are loaded into memory, leading to very fast / low RAM footprint lookups for the majority of points.

4. Polygon files are only used, for the small number of points that can’t be resolved through shortcuts (if I got it right, you aren’t loading the whole file into memory to do the lookups, but use a file cursor instead, correct?).