Code Monkey home page Code Monkey logo

tz-lookup-oss's Introduction

tz-lookup

This is a little Javascript library that allows you to look up the time zone of a location given its latitude and longitude. It works in both the browser and in Node.JS, and is very fast and lightweight (~71KB) given what it does. We use it in production for The Dark Sky API.

This library is no longer actively maintained under an Open Source license. Please fork it if you would like to continue development.

Usage

To install:

npm install tz-lookup

Node.JS usage:

var tzlookup = require("tz-lookup");
console.log(tzlookup(42.7235, -73.6931)); // prints "America/New_York"

Browser usage:

<script src="tz.js"></script>
<script>
alert(tzlookup(42.7235, -73.6931)); // alerts "America/New_York"
</script>

Please take note of the following:

  • The exported function call will throw an error if the latitude or longitude provided are NaN or out of bounds. Otherwise, it will never throw an error and will always return an IANA timezone database string. (Barring bugs.)

  • The timezones returned by this module are approximate: since the timezone database is so large, lossy compression is necessary for a small footprint and fast lookups. Expect errors near timezone borders far away from populated areas. However, for most use-cases, this module's accuracy should be adequate.

    If you find a real-world case where this module's accuracy is inadequate, please open an issue (or, better yet, submit a pull request with a failing test) and I'll see what I can do to increase the accuracy for you.

Sources

Timezone data is sourced from Evan Siroky's timezone-boundary-builder. The database was last updated on 6 Jan 2019.

To regenerate the library's database yourself, you will need to install GDAL:

$ brew install gdal # on Mac OS X
$ sudo apt install gdal-bin # on Ubuntu

Then, simply execute rebuild.sh. Expect it to take 10-30 minutes, depending on your network connection and CPU.

License

To the extent possible by law, The Dark Sky Company, LLC has waived all copyright and related or neighboring rights to this library.

tz-lookup-oss's People

Contributors

peterkhayes avatar plampila avatar ssoper avatar thegrossman avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

tz-lookup-oss's Issues

rebuild.sh errors

After installing ImageMagick and gdal, which isn't mentioned in the docs (added pull request), I am still getting these errors.

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   611    0   611    0     0   2284      0 --:--:-- --:--:-- --:--:--  2288
100 33.9M  100 33.9M    0     0  14.7M      0  0:00:02  0:00:02 --:--:-- 22.4M
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   362  100   362    0     0    576      0 --:--:-- --:--:-- --:--:--   576
  0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
100   362  100   362    0     0    529      0 --:--:-- --:--:-- --:--:--   529
Archive:  timezones.geojson.zip
  inflating: dist/combined.json
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
0...10...20...30...40...50...60...70...80...90...100 - done.
convert-im6.q16: Unknown field with tag 33550 (0x830e) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 33922 (0x8482) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 34735 (0x87af) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 34736 (0x87b0) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 34737 (0x87b1) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/244.
convert-im6.q16: cache resources exhausted `tz_a.tiff' @ error/cache.c/OpenPixelCache/3945.
convert-im6.q16: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/244.
convert-im6.q16: cache resources exhausted `tz_a.tiff' @ error/cache.c/OpenPixelCache/3945.
convert-im6.q16: no images defined `tz_a.pgm' @ error/convert.c/ConvertImageCommand/3258.

Errors Only

convert-im6.q16: Unknown field with tag 33550 (0x830e) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 33922 (0x8482) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 34735 (0x87af) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 34736 (0x87b0) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: Unknown field with tag 34737 (0x87b1) encountered. `TIFFReadDirectory' @ warning/tiff.c/TIFFWarnings/912.
convert-im6.q16: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/244.
convert-im6.q16: cache resources exhausted `tz_a.tiff' @ error/cache.c/OpenPixelCache/3945.
convert-im6.q16: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/244.
convert-im6.q16: cache resources exhausted `tz_a.tiff' @ error/cache.c/OpenPixelCache/3945.
convert-im6.q16: no images defined `tz_a.pgm' @ error/convert.c/ConvertImageCommand/3258.

incorrect TZ for Page, AZ

Page, AZ - 36.9147, -111.4558 - should be in America/Phoenix (no DST) and not in America/Denver TZ

I added test in pirxpilot/tz-lookup repo

Not sure if this is a problem with incorrect shapefile DB or an issue in tz-lookup. I emailed Eric Muller - I'll let you know if I get a response.

[Q] Why tz-lookup needs NaturalEarth's urban areas and populated places data?

(This is a question about this project. If there is a better place for questions, please let me know. I'll move this question to there)

I think location-to-timezone lookup can be done by using Timezone-Boundary-Builder's combined.json only. So I can not fully understand why tz-lookup needs additional NaturalEarth's urban areas and populated places data.

I guess the reasons are...

  • tz-lookup uses rasterized data of combined.json to reduce lookup time and load, rather than uses combined.json directly,
  • To reduce size of the rasterized data, critical areas are rasterized in fine resolution and less critical areas in coarse resolution.
  • NaturalEarth's urban areas and populated places data are used to determine the critical areas.

Is my guess right?

Resolve conflicting timezones somehow

Depends on #29

From 2018g on, there are several regions where timezones conflict with each other. In #29, I took the approach of simply picking one (by hand). This imposes my own biases and opinions on a complicated situation, though, and is probably not a great way to go.

We should figure out a better model for how to handle this. This almost certainly involves changing the interface to the library.

Upgrade to 2018i

timezone-boundary-builder 2018g is out. tz-lookup should upgrade to it.

Unfortunately, this release made a radical change: timezone boundaries are now allowed to overlap (and do, in many disputed areas). This violates a necessary assumption of this library in two ways:

  1. The data storage format treats the earth as a bitmap where each pixel has only a single color. The format would need to be extended to support the assumption that there are overlaps.
  2. The interface to this library assumes that there is one—and exactly one—timezone for a given latitude and longitude. We'd need to change the interface to remove this assumption, and ideally support some kind of mechanism for disambiguating which timezone is the desired one. (I haven't the slightest idea how to do this, though, as I'm not familiar with the nature of the overlapping/disputed regions. Some research is necessary.)

Lookup historical timezones

Timezone mapping is a political designation, and therefore changes over time. We've occasionally received requests for being able to lookup timezones in the past, and this would be an interesting technical challenge.

There are two components to it, I believe:

  1. Changing the 2D quadtree storage format into a 3D octree storage format. This is not complicated.
  2. Obtaining historical mappings of timezones. Presumably, we'd want a series of 2D maps, each of which corresponds to the timeslice at each timezone data change.

At lookup, we'd find the X (longitude: linear mapping from degrees), Y (latitude: linear mapping from degrees), and Z (time: binary search of data array corresponding to the data from [2]) coordinates of the data we want, and then simply traverse the octree similarly to how we presently traverse the quadtree.

The data file would become larger, but not horribly so; most timezones haven't changed too much over time, so the octree should compress things very well. At worst, we can move back to static binary data, gzip it, and gunzip it again at runtime.

So, this is all straightforward except obtaining the raw source data. Is that available anywhere?

client side usage

I am experimenting with using tz-lookup on the client. Feel free to close this issue if this is something that you are not interested in or have a different vision for.

I have a working version implemented in browser-friendly branch of my fork

Some things to consider:

  • node's Buffer replacement - ArrayBuffer, typed Arrays and DataView - nothing controversial here I hope
  • need to move tz.bin to client - I chose to do that by providing tz.bin configuration in HTML dataset and then using fetch to actually download the data... - there are other ways to do that, I chose this one since it's compatible with using cachify, service workers and CDNs
  • initialization - which involves downloading and converting (byte order!) tz.bin - has to be asynchronous on the client (or so I think) - to make things easier I changed the server init to be async as well. That makes it easy for browserify to use a different init module on the client, but it makes things more complicated on the server. Maybe we should have an optional sync init as well?
  • rolled back some ES6 (const and let) changes - since I didn't think it's worth transpiling just for that, but it's simple to revert

In any case - if you're interested please have a look at my branch and let me know what you think.

Be smarter about poles?

This library handles the North and South pole stupidly:

> tz(-90, -90)
'Etc/GMT+6'
> tz(-90, 0)
'Etc/GMT'
> tz(-90, 90)
'Etc/GMT-6'

...but what should we do? Special case exactly -90 and +90 to return Etc/GMT?

A couple of places in Sweden is Finnish according to tz-lookup, but it is not!

We use tz-lookup at the Swedish Meteorological and Hydrological Institute to calculate sunrise and sunset for different latitudes and longitudes. When we use it to find the timezone for a couple of place in the archipelago in Sweden, Europe/Mariehamn time is returned. The places are however parts of Sweden and should return Europe/Stockholm. Is it possible to fix this?

The places we have identified are these:

  • Grisslehamn (Norrtälje)
  • Ortala (Norrtälje)
  • Tomta (Norrtälje)
  • Björkkulla (Norrtälje)
  • Kvarnsand (Norrtälje)
  • Semmersby (Norrtälje)
  • Gamla Grisslehamn (Norrtälje)

Kind regards / Lena Gripenblad, SMHI

Lookup up timezones for quadrangle areas

Right now, it's only possible to look up timezones for point locations.

It would be nice to be able to look up timezones for a rectangular area (e.g. a bounding box/quadrangle). I could see three possible interfaces for this:

  1. If the area is completely contained within a single timezone, return that timezone; if not, return "Etc/UTC".
  2. If the area is completely contained within a single timezone, return that timezone; if not, return whichever timezone has the most coverage within the area.
  3. Always return an array of all timezones covered by the location. (In the case of a point, this will always be a list of length 1; in the case of an area, the array will be of length >= 1.) If we want to be really nice, this list could be sorted by amount of coverage within an area.

Malören in the Kalix Archipelago in Sweden is Finnish according to tz-lookup (it is not)

When I user tz-lookup to fins the timezone for Malören in the Kalix Archipelago in Sweden (65.85/23.1333333), Europe/Helsinki is returned. It is however a part of Sweden and should return Europe/Stockholm. We use this module at the Swedish Meteorological and Hydrological Institute to calculate sunrise and sunset for different latitudes and longitudes. Is it possible to fix this?

Typescript type definitions

For those interested, these are the type definitions when you want to use tz-lookup with TypeScript:

declare module 'tz-lookup' {
  function tzlookup(lat: number, lng: number): string;
  let x: typeof tzlookup;
  export = x;
}

Resolution is bad around Northern Ireland|Ireland border

units=auto is not precise in this area. Northern Ireland border is not specified as uk. The following are all lat, longs from the Northern Ireland side and whether they read as uk or not (they all should).

55.1813793,-6.9533839 uk
55.0077972,-7.360391 uk
54.8262813,-7.474688 uk
54.7114315,-7.7070063 not
54.6818704,-7.8587107 not
54.6299392,-7.7590031 not
54.5916096,-7.733996 not
54.3358946,-7.9214402 not
54.2136435,-7.7376801 not
54.1516816,-7.3570611 not
54.2400902,-7.1780967 not
54.4296313,-7.0015598 not
54.2056867,-6.7383513 not
54.0689954,-6.5307476 uk
54.1105096,-6.2669591 uk
54.0388961,-6.0936587 uk
54.2187387,-5.8881492 uk

these points go along the border from northwest to southeast.

why uglify ?

how to use the project without uglified data.
there is some inconsistency in the module and i would like to debug and while its uglified its hard to debug and create issues.

Update to tz2016b

From Eric Muller's TZ timezone maps

March 20, 2016:

  • updated to tz2016b:
    • introduced Asia/Barnaul, Europe/Astrakhan, Europe/Ulyanovsk.
    • Durango state in Mexico is entirely in America/Monterrey
    • Baja California state in Mexico is entirely in America/Tijuana (and America/Santa_Isabel no longer exists).
    • properly label Busingen with Europe/Busingen.
  • added SHA-1 of the zip files.

Time zone for some Swedish places are wrongly Finnish according to tz-lookup

We use tz-lookup at the Swedish Meteorological and Hydrological Institute to calculate sunrise and sunset for different latitudes and longitudes. When we use it to find the timezone for a couple of place near the Finnish boarder in the northern Sweden, Finnish time is returned. The places are however parts of Sweden and should return Europe/Stockholm. Is it possible to fix this?

The places we have identified are these:

  • Saivomuotka
  • Muonionalusta
  • Muoniovaara
  • Ruosteranta
  • Kätkesuando

Kind regards / Lena Gripenblad, SMHI

Universal and Clinton, Indiana, are in America/New_York

But we think that Universal and Clinton, Indiana, are in America/Chicago.

09:16:58 (master) ~/src/tz-lookup$ node
> const tz = require("./tz")
undefined
> tz(39.6216875,-87.4522356)
'America/Chicago'
> tz(39.6631031,-87.4306705)
'America/Chicago'

Use timezones-with-oceans shapefiles

Depends on #29

I think we're at the point where the rebuild system can handle using the timezones-with-oceans distribution. Doing so would simplify the build script a little bit and push more of this library's logic onto @evansiroky (which is, of course, a good thing for me ;) ).

Wrong timezone for parts of nothern Sweden

Hi!
For Muodoslompolo and Kitkiöjärvi in nothern Sweden (67.9333,23.4333 and 67.81667,23.16667) you get timezone Europe/Helsinki. It should be Europe/Stockholm.
Regards,
Tomas Funquist

Update tz.bin

From README

The timezone database was last updated on 26 Nov 2013.

From http://efele.net/maps/tz/world/

History:

  • May 5, 2014:
    • added the missing tz_greenland_mask shapefile to the ingredients. Thanks to Blake Crosby for reporting the problem.
  • November 26, 2013:
    • fixed a problem along the boundary of America/Menominee and Lake Michigan. Thanks to James Diebel for reporting the problem.

Resolution poor at part of the new brunswick|maine border

below are some points on the new brunswick side and whether or not they are assigned ca timezone:
45.1951884,-67.2752883 ca
45.3777282,-67.4134159 ca
45.6503965,-67.5789868 not
46.4391796,-67.7449724 not
47.1693744,-67.919151 ca
47.3709641,-68.3190054 ca
correct timezone is "America/Moncton", incorrect points show "America/New_York".

json2bin doesn't work

Followed your instructions to update the data, but your json2bin doesn't do anything for me. It prints out TIMEZONE_LIST array, creates an empty tz.bin and never exits. I'm guessing broken somewhere?

incorrect timezones in Wisconsin and Newfoundland

Furkot users found 2 places that are incorrectly classified:

Whitefish Dunes State Park, Wisconsin
44.9280, -87.1853 - should be "America/Chicago"

Port au Choix, NL, Canada
50.7029, -57.3511 - should be "America/St_Johns"

I verified that I can fix them both by using force_urban in pack.js

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.