#timezone #latitude #longitude #finder #time #convert #name

bin+lib tzf-rs

Fast convert longitude,latitude to timezone name

18 releases

0.4.8 Apr 12, 2024
0.4.7 Mar 16, 2024
0.4.5 Dec 29, 2023
0.4.4 Aug 19, 2023
0.1.3 Nov 28, 2022

#19 in Geospatial

Download history 532/week @ 2024-02-15 1013/week @ 2024-02-22 1423/week @ 2024-02-29 1537/week @ 2024-03-07 1485/week @ 2024-03-14 1209/week @ 2024-03-21 1016/week @ 2024-03-28 1196/week @ 2024-04-04 1790/week @ 2024-04-11 1522/week @ 2024-04-18 1164/week @ 2024-04-25 875/week @ 2024-05-02 1059/week @ 2024-05-09 1238/week @ 2024-05-16 1032/week @ 2024-05-23 835/week @ 2024-05-30

4,315 downloads per month
Used in 4 crates

MIT license

155KB
387 lines

tzf-rs: a fast timezone finder for Rust. Rust Documentation

Time zone map of the world

[!NOTE]

This package uses simplified shape data so it is not entirely accurate around the border.

Build options

By default, the binary is built as well. If you don't want/need it, you can omit the default features and build like this:

cargo build --no-default-features

Or add in the below way:

cargo add tzf-rs --no-default-features

Best Practices

It's expensive to init tzf-rs's Finder/FuzzyFinder/DefaultFinder, so please consider reusing instances or creating one as a global variable. Below is a global variable example:

use lazy_static::lazy_static;
use tzf_rs::DefaultFinder;

lazy_static! {
    static ref FINDER: DefaultFinder = DefaultFinder::new();
}

fn main() {
    print!("{:?}\n", FINDER.get_tz_name(116.3883, 39.9289));
    print!("{:?}\n", FINDER.get_tz_names(116.3883, 39.9289));
}

For reuse, racemap/rust-tz-service provides a good example.

A Redis protocol demo could be used here: ringsaturn/redizone.

Performance

The tzf-rs package is intended for high-performance geospatial query services, such as weather forecasting APIs. Most queries can be returned within a very short time, averaging around 3,000 nanoseconds (about 1,000ns slower than with Go repo tzf. I will continue improving this - you can track progress here).

Here is what has been done to improve performance:

  1. Using pre-indexing to handle most queries takes approximately 1000 nanoseconds.
  2. Using a finely-tuned Ray Casting algorithm package ringsaturn/geometry-rs to verify whether a polygon contains a point.

That's all. There are no black magic tricks inside the tzf-rs.

Below is a benchmark run on global cities(about 14K), and avg time is about 3,000 ns per query:

test benches_default::bench_default_finder_random_city ... bench:       2,870 ns/iter (+/- 182)
Criterion result Pic
PDF
Regression

You can view more details from latest benchmark from GitHub Actions logs.

References

I have written an article about the history of tzf, its Rust port, and its Rust port's Python binding; you can view it here.

Bindings

LICENSE

This project is licensed under the MIT license. The data is licensed under the ODbL license, same as evansiroky/timezone-boundary-builder

Dependencies

~14MB
~71K SLoC