The most up-to-date and accurate node.js geographical timezone lookup package. It's fast too!
npm install geo-tz
const { find } = require('geo-tz')
find(47.650499, -122.350070) // ['America/Los_Angeles']
find(43.839319, 87.526148) // ['Asia/Shanghai', 'Asia/Urumqi']As of Version 7, there is no longer a default import. The find function should be used instead.
As of Version 5, the API now returns a list of possible timezones. There are certain coordinates where the timekeeping method will depend on the person you ask. Also, another case where 2 or more timezones could be returned is when a request is made with a coordinate that happens to be exactly on the border between two or more timezones.
Returns the timezone names found at lat, lon. The timezone names will be the timezone identifiers as defined in the timezone database. The underlying geographic data is obtained from the timezone-boudary-builder project.
This library does an exact geographic lookup which has tradeoffs. It is perhaps a little bit slower that other libraries, has a larger installation size on disk and cannot be used in the browser. However, the results are more accurate than other libraries that compromise by approximating the lookup of the data.
The data is indexed for fast analysis by caching subregions of geographic data when a precise lookup is needed.
By default, geoTz lazy-loads exact lookup data into an unexpiring cache. The setCache method can be used to change the caching behavior using the following options:
preload- if set to true will attempt to cache all files (slow startup time and requires lots of memory)store- offload the cache to a custom storage solution (must be compatible with the Map api)
Examples:
setCache({ preload: true }) // preloads all files
let map = new Map();
setCache({ store: map }) // pass a Map-like storage objectThis library is not intended to be used in the browser due to the large amount of files that are included to perform exact geographic lookups.
Due to the ever-changing nature of timezone data, it is critical that you always use the latest version of this package. If you use old versions, there will be a few edge cases where the calculated time is wrong. If you use greenkeeper, please be sure to specify an exact target version so you will always get PR's for even patch-level releases.