#timezone #coordinates #latitude-longitude #geospatial #time #gps #system-clock

spatialtime

A simple library to lookup longitude + latitude pairs, using flatgeobufs

4 releases

0.2.0 Aug 15, 2024
0.1.5 Aug 9, 2024

#270 in Date and time

Download history 220/week @ 2024-08-06 116/week @ 2024-08-13 4/week @ 2024-09-10 2/week @ 2024-09-17 23/week @ 2024-09-24 62/week @ 2024-10-01 8/week @ 2024-10-08

93 downloads per month

MIT license

13KB
163 lines

spatialtime

Crates.io Version Documentation License:MIT

A Rust library to lookup timezone data based on longitude and latitude. Only focused on the offline environment, in which the system clock cannot be trusted at all (thus, no DST adjustments). Uses the Natural Earth (NED) and OpenStreetMap (OSM) datasets, pre-processed into flatgeobufs for indexed queries.

Inspo

The idea and some conventions are heavily influenced by rtz, which is an awesome library that is probably fine for most people. At the time of writing, however, it only worked with nightly Rust. So I have gone forward with this much simpler implementation for stable Rust, that fits the specific use-case I am trying to solve.

Install

# use NED
spatialtime = { version = "0.2", features = ["ned"] }
# use OSM
spatialtime = { version = "0.2", features = ["osm"] }

Usage

let response = spatialtime::osm::lookup(-77.0365, 38.8977).unwrap();
/***
 *  OSM dataset does not include offset, just tzid
 *  OsmResponse { tzid: "America/New_York" }
 ***/
let response = spatialtime::ned::lookup(149.1165, -35.3108).unwrap();
/***
 *  NED dataset will always contain offset, but might not have a tzid
 *  NedResponse { offset: 10.0, tzid: Some("Australia/Sydney") }
 ***/

OSM or NED?

OSM dataset is much larger, coming in at 17.9MB. NED is 890KB. OSM may be more "accurate" and more "up-to-date", but which one you use is likely case-by-case.

Data Sources

Dependencies

~13–23MB
~340K SLoC