mattjohnsonpint / geotimezone

Provides an IANA time zone identifier from latitude and longitude coordinates.

GeoTimeZone

Provides an IANA time zone identifier from latitude and longitude coordinates.

Nuget Installation

PM> Install-Package GeoTimeZone

Supported Environments

As of version 5.0.0, GeoTimeZone works with all of the following:

• .NET 5 or greater
• .NET Core 2.0 or greater
• .NET Framework 4.6.2 and greater

Note that .NET Framework versions less than 4.6.2 are no longer supported.

Example Usage

string tz = TimeZoneLookup.GetTimeZone(50.4372, -3.5559).Result;  // "Europe/London"

Usage Notes

This library returns IANA time zone IDs. If you need a Windows time zone ID, pass the return value into the TimeZoneConverter library's TZConvert.IanaToWindows method, or to TZConvert.GetTimeZoneInfo to get a TimeZoneInfo object in a platform-neutral manner.

This library uses the time zone border definitions from the Timezone Boundary Builder project, which in-turn derive from Open Street Map. As some international borders are the subject of dispute, the results may or may not align with your worldview. Use at your own risk.

Acknowledgements

Huge thank you to the following people:

• Evan Siroky, who tirelessly maintains the Time Zone Boundary Builder project, which we use for our source data.
• Eric Muller, who authored the original tz_world data set (now deprecated in favor of TBB).
• Simon Bartlett, who contributed all the polygon indexing and lookup bits to this library.
• Sharon Lourduraj, who wrote GeoHash-net that we used for our original implementation.
• David Troy, who wrote Geohash-js that Sharon later ported to .NET
• Nick Johnson, who's excellent blog post has been an inspiration to this project and so many others!
• Jonas Nyrup, who has helped with performance optimizations.

License

This library is provided free of charge, under the terms of the MIT license.

geotimezone's Issues

Western arizona returns America/Los_Angeles

Lat long of 34.15, -114.26, which is Avi Suquilla airport returns Los_angeles rather than Phoenix.
Phoenix is returned as an alternate, but this location is definately across the border, and an airport, which can be especially problematic.

update of tz_world at runtime

Would it be possible to update tz_world at runtime in order to have an updated world view without having to update GeoTimeZone on a running instance?
Similiar to NodaTime

Return Windows Time Zone IDs

This library returns IANA identifiers which I soon found out via a TimeZoneNotFoundException that they are not useful in Windows. If I could get the actual UTC offset and whether there is DST or not, then it would be useful.

In order to get this to work I had to plug the TimeZoneConverter NuGet to convert these IANA codes from here into something I could use in Windows to get the UTC time offsets and convert dates.

It would be nice if this library provided the information we are missing.

Convert to PCL

A primary consumer of this library will be mobile applications, so we should be targeting PCL with support for Windows Phone, Xamarin iOS & Android.

We may not have a need for a non-PCL build at all, unless we run into some strange dependency. So the current GeoTimeZone.Net40.csproj may ultimately be deleted.

Nautical calc should take intl date line into consideration

The international date line doesn't follow a single line of longitude. We need to take that into consideration.

This could affect nautical zones from UTC-10 to UTC+14. We currently aren't considering +13 or +14.

Not sure where to get a shapefile for the international date line, or how we would consume it. Thoughts?

Handle Antarctica time zones

Most of the Antarctica time zones are in their own shapefile made up of points instead of polygons.
http://efele.net/maps/tz/antarctica/

We may want to include this data and just us a nearest-point algorithm.

East India misdetection

https://www.timeanddate.com/time/zone/india/agartala
Lat : 23.88
Lon : 91.25

Detects Timezone : Asia/Dhaka UTC+6 (and wrong country Bangladesh)
Should be : India Standard Time UTC+5,5

Keep up the good work!

Timezone misplaced to South Africa instead of Europe Estonia

This test fails:

[Test]
public void TimeZoneFromCoordinates()
{
    double latitude = 59.470977;
    double longitude = 24.708448;                        
    string timeZoneId = TimeZoneLookup.GetTimeZone(latitude, longitude).Result;
    Assert.True(timeZoneId.Equals("Europe/Tallinn"), "{0}, {1} Is Europe/Tallinn 
                                                        but Was Identified As {2}", latitude, longitude, timeZoneId);
}

The output is:
59.470977, 24.708448 Is Europe/Tallinn but Was Identified As Etc/GMT-2

And GMT-2 is ambiguous so using e.g. NodaTimeZoner.IanaToWindows("Etc/GMT-2") returns South Africa Standard Time instead of the correct FLE Standard Time. I.e. it places these coordinates on a completetly different continent.

I'm guessing the result is something to do with nautical time zones (#6) or territorial waters (#8), but don't really understand the concepts to dig further.

However, the coordinates under test are actually on land:
https://www.freemaptools.com/radius-around-point.htm?clat=59.4709767&clng=24.7084479&r=0.1&lc=FFFFFF&lw=1&fc=00FF00

And less than 8km driving from centre of Tallinn according to Google Maps (less than 12 nautical miles)?

Or is the underlying shape data inaccurate (excluding parts of this coastal capital)?

In any case, the result is wrong:

• is it possible to fix it properly?
• if not, are there any workarounds I could employ? It's pretty bad to miss by 15000km (from Estonia to South Africa)
• For instance, do I understand correctly that anything starting with Etc is located in the waters, so as a hack I could ignore all results starting with Etc?

Russian island misdetection?

Preodrasheniyai
Lat : 74.667
Lon: 112.5
https://www.google.com/maps/place/74%C2%B040'01.2%22N+112%C2%B030'00.0%22E/@74.6221272,114.7780538,6.19z/data=!4m4!3m3!8m2!3d74.667!4d112.5

Detects : UTC+7 Asia/Krasnoyarsk
Should be (???) : UTC+9 ? https://www.timeanddate.com/time/zone/@74.667,112.5
Near spot"Nordwik" has UTC+7 https://www.timeanddate.com/time/zone/@2021666
So I'm not sure what is correct here.

Keep up the good work!

Update for 2017c

https://github.com/evansiroky/timezone-boundary-builder/releases/tag/2017c

GeoTimeZone and Powershell

Hi, can I use GeoTimeZone inside powershell script? if yes can yu please let me know how?
Thanks

Update tz_world data

The data should be updated and the disclaimer removed from the README.

The source data (tz_world) has been updated to tzdb 2015g.

Timezone incorrect for Africa/Ceuta

Hi,

the following code should return Africa/Ceuta, but instead returns Africa/Casablanca:
double latitude = 35.8894012908865;
double longitude = -5.30445597754788;
Console.WriteLine(TimeZoneLookup.GetTimeZone(latitude, longitude).Result);
I checked the time zone in OpenStreetMap: https://www.openstreetmap.org/relation/1154756#map=7/35.885/-5.317

Issue with the installation of the BarcodeLib Library

my problem is the following: I am installing the BarcodeLib library to generate barcodes, but it gives me the following error:

Package 'BarcodeLib.2.2.5' does not exist in project 'UI' Could not install package 'BarcodeLib 2.2.5'. You are trying to install this package into a project that targets '.NETFramework, Version = v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author. ========== Finished ==========

I rename the folder as indicated here: https://stackoverflow.com/questions/42039069/could-not-install-package-you-are-trying-to-install-this-package-into-a-pr

It is installed correctly, but when I try to call the library, it does not appear, I leave a photo, to make it clearer, I hope you understand me and help me.

offestHours reversal.

MSSQL/PostgreSQL data builder

We currently use NTS for all of our geospatial calculations. There is a small issue though, because NTS only handles calculations based on a Euclidean plane.

The Earth is a spheroid, and because of that, we should ideally be using a WGS-84 projection.

Unfortunately, there are no libraries that support the spatial calculations we require on a WGS-84 projection... so we would have to use the spatial support in either MSSQL or PostgreSQL.

Rename Asia/Rangoon TZ to Asia/Yangon

The Asia/Rangoon TZ has been renamed to Asia/Yangon (see ftp://ftp.iana.org/tz/tzdb/asia for further details) but TZL.dat still references Asia/Rangoon.

Compress data

Have you considered compressing TZ.dat just as with data.json.gz in TimeZoneNames?

As I read the code the additional decompressing would be a one-time penalty when reading TZ.dat.

My raw test of gzipping TZ.dat shows that would be reduced from 9.82 mb to 1.56 mb.

Updates?

Is there any support (or plans to implement support) for runtime updates to the boundaries data files, so we don't have to rebuild with nuget updates, to get fresh data?

The type 'System.Object' is defined in an assembly that is not referenced.

I added a reference to the GeoTimeZone.dll file which I extracted from the Nuget package like so.

The only line of code I am using the library for is this: string timezone = TimeZoneLookup.GetTimeZone(latitude, longitude).Result;

But I keep getting an error when compiling: Error #CS0012 on line 86 - The type 'System.Object' is defined in an assembly that is not referenced. You must add a reference to assembly 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51'. (09:26:01) Compilation error. See logs/errors/compiler.log for more information.

I have also referenced netstandard.dll using the same method of NuGet extraction yet the issue still persists.

Optimize the data for runtime

Currently, the shapefile is being read from disk. It actually is in multiple files (.shp, .shx, .dbf, .prj) that have to all be in the same directory.

We should create a "data builder" that reads from the shapefile at build time, and outputs some intermediate format for runtime. The format might be WKT, WKB, GeoJSON, or just some binary-serialized custom format. The choice of format will be mostly determined by what we can do at runtime (see #1).

The data will ultimately need to be put into an embedded resource and compiled with the main dll.

Optimize Spatial Routines

NetTopologySuite is great, but it is quite large. The only things we require are:

• Ability to find out whether a point exists within a polygon.
• Ability to find the closest polygon within a set distance from a point when the point is not in a particular polygon (for territorial waters).
• Ability to deserialize polygons from some format. (Does not have to be a shapefile. See #2 )

We should be looking for pure managed code that we can internalize into this library, rather than an external reference. (The end result would be a single dll with no dependencies.)

Failing Test: Can_Lookup_Where_Two_Countries_Meet

6e5ad4c

The test was giving a false positive because the ID strings where transposed. I'm not sure if it's a precision issue or not. Perhaps related to #10?

Geohash precision

The current implementation uses geohashes that are 5 characters in length. This gives a worst case precision of ~4.9km.

This imprecision mostly affects us where two or more time zones meet each other. There are cases where a geohash intersects with multiple timezones, and we currently just pick one time zone and discard the others.

I propose we either do one of the following:

1. Record all matches in the index. When a search matches multiple geohashes, we provide the caller all possible matches. The result object could have two properties:
   SuccessfulMatch and PossibleMatches.
2. We continue as is, but we introduce a byte per line that signals how accurate the result is.

I prefer the first option, but would appreciate your thoughts.

Getting Europe/Moscow instead Europe/Tallinn

By using TimeZoneLookup.GetTimeZone(59.37, 28.19).Result
I getting Europe/Moscow it should be Europe/Tallinn

Update to latest timezone boundary builder release

https://github.com/evansiroky/timezone-boundary-builder/releases

Strong name the library

The guidance from the .NET team has changed, and is now clear that OSS libraries should be strong named.

https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/strong-naming

This will be a breaking change
https://haacked.com/archive/2012/02/16/changing-a-strong-name-is-a-major-breaking-change.aspx/

Addresses previous request #25

Data File Format

The data files we have work, but are rather large. We can probably do better. Some ideas:

• A binary format might work better than text
• Probably should have a header with details such as how many entries are in the file. That will also allow us to just have one file, as the fixed-width entries can be near the top while the variable-width entries could be at the bottom.
• We might want to gzip the data before embedding it, though that would require decompression of the entire file into memory before using it. Not sure it we want to do that or not. (depends on how fast it loads.)

Output Format

We're currently output just a string with the IANA name of the time zone. We should instead return an object that has this as a property.

Other properties could be:

• The Windows ID of the time zone if available (see #4)
• The Standard Offset from UTC
• The Daylight Offset from UTC if the TZ has daylight time
• Names and abbreviations (possibly)

We'll want to be careful here not to overlap too much with NodaTime For example, i don't want to attempt to tell you which name or abbreviation to use or which offset is currently in effect.

There's already a minor issue in that even the standard offset might have changed in the history, but I think it's still worth returning the current standard offset,

Switch to OSM time zone boundaries

The boundaries created by the Time Zone Boundary Builder project use Open Street Map (OSM) data, which appear to be more accurate than the tz_world map sources, and include territorial waters, which simply coast lines and address our issue #8.

We should switch to this source.

Handle time zones in territorial waters

If a point is not found on a land mass, then it must be at sea. Most of the time, it can be calculated by simple formula. (see #6)

However, if it is within 12 nautical miles (22.2 km) of land, then it is considered to be in territorial waters, and thus the time zone is that belonging to the closest land mass.

We need to somehow account for this. It is particularly important for areas like the Philippines where there are lots of little islands.

Perhaps when building the data file, we could find polygons that have no bordering polygons and simply extend them? I can envision that resolving overlaps might be difficult. Is there a way to do this?

Arizona timezones incorrect

When calling TimeZoneLookup.GetTimeZone(latitude, longitude), locations in Arizona are being returned as America/Los_Angeles instead of America/Phoenix

samples:
35.109183, -114.598155 zip code 86442
35.103325, -114.597998 zip code 86442
35.108012, -114.610273 zip code 86442
32.698297, -114.581565 zip code 85365
35.082686, -114.596978 zip code 86442
35.088242, -114.598138 zip code 86442
34.503053, -114.350817 zip code 86403
32.698399, -114.623759 zip code 85364

MapTZID with 'current' names

Handle nautical time zones

Time zones at sea are determined not by shapefile lookup, but by calculation based on their longitude.

If a point is not found in a shapefile, we should first see if it's in territorial waters (<= 22km near land), and if not then we should calculate the nautical time zone and return that instead.

Update to 2022g

Hi!

Is it possible to update data to latest 2022g timezone-boundary-builder?

Thanks in advance! :)

CLDR Conversions

I'd like to include the CLDR conversion data so we can emit both the IANA time zone and the corresponding Windows time zone id.

That will allow those who are tied to TimeZoneInfo to still use this library.

Referenced Assembly xxx does not have strong name

Hi,
Can you please sign the assembly with some generated key? I cannot use the nuget package right now because the assembly is not signed.
Thx
Michael

Use a more efficient search algorithm

Currently, we are just iterating through all polygons and returning the first match. We should consider using a more efficient method, such as pre-calculating a GeoHashTree index. This may be difficult, since we don't want to take a dependency on any database.

getting error while trying to install Microsoft.Bot.Builder.AI.Luis version 4.5.1

getting following error while trying to install Microsoft.Bot.Builder.AI.Luis version 4.5.1

Severity Code Description Project File Line Suppression State
Error Could not install package 'Microsoft.Bot.Builder.AI.Luis 4.5.1'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.7.1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author. 0

Class to return Windows Time Zone Id (System.TimeZoneInfo.Id)

Hi Matt,

I'd like to request that you add another method to the TimeZoneLookup class which returns the Windows TimeZone Id for a given latitude and longitude. e.g. TimeZoneLookup.GetWindowsTimeZone(latitude, longitude).

As far as I know GeoTimeZone is the only .NET library out there for converting GPS coordinates to timezone, so I think being able to return Windows Time Zone Id directly is an extremely useful feature to have.

Thanks!

Mark Janos

Refocus

Ok, time to get back to business. This project has sat idle for far too long. (my bad!) :)

I'd like to refocus to let this solve one problem and one problem only - which is lat/lon to IANA Time Zone ID. Anything else is out of scope.

Motivation:

• Noda Time is portable, and can do IANA to Windows translations, TZDB offset calculations, and much much more.
• I've built a separate library called TimeZoneNames, which provides localized names and abbreviations from CLDR. Therefore, there's no good reason to do it here also.

Additionally, I don't like the gzip stuff I added at the end. It takes too long to decompress.

Alabama lat long returning New York from GetTimeZone method

The GetTimeZone method is giving "America/New_York" when I pass the lat long of Alabama (32.4681,-85.00083). Please check below fiddle for details:
Alabama location giving New York
Open street map for same location

Change Asia/Kolkata to Asia/Calcutta

Asia/Kolkata is not a valid timezone. It should be Asia/Calcutta instead.

Australian Timezone Incorrect

Given these coordinates: -28.19780000, 153.53460000

I expect to see "Australia/Sydney" but I am seeing "Australia/Brisbane"

Possible to improve accuracy?

Hi there, I'm hoping to use this project but I was noticing inaccurate timezone borders. Out of curiosity I visualized what GeoTimeZone was producing onto google maps. Here is an example of Indiana which does a good job showing issues with the east/west side of the state as well as the southern portion where there are a set of timezones separated by rivers

This is a little too far off for me to use in the current state so I was wondering is there a way to compile this project so that time zones are more accurate? Perf isn't too big of a concern.

Thanks!

How to get the timezone in number?

Hi,

How can I get the timezone in numbers, for example +3, -4, etc?

Thanks,
Jassim

How about .Net Time zone standard?

Can I get .Net standard id of time zone?
For example: TimeZoneLookup.GetTimeZone(50.026034, 36.224942).Result
actual result: "Europe/Kiev"
expected result: "FLE Standard Time"

https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/default-time-zones

Getting America/Los_Angeles instead of America/Vancouver near border

Hi there, I put in a lat/lng of (49.0427211, -122.8466416) which should return "America/Vancouver" but fails to do that, and return Etc/GMT+8 where the offset is wrong, should be -8, I tried debugging through the TimeZoneLookup call and narrowed it down to
line 14 in class TimeZoneLookup: var lineNumber = GetTzDataLineNumbers(geohash); Hoping you can clarify what's happening there. Thanks

Karn

Nuget installation issues targeting .Net Framework 4.5.2 and lower.

Greetings,

I tried to add GeoTimeZone to my web api project and I get the following error:
Could not install package 'System.Runtime 4.0.20'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.5.2', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.

Thank you for your help

With regards,

Marko

Bullhead City, AZ incorrectly identified as PST

Originally reported here: evansiroky/timezone-boundary-builder#103

The lat and long for Bullhead City, AZ is being identified as Pacific Time Zone. It should be MST. I do see an alternative result that is MST, but that should be the primary result, not the secondary, correct?

OpenMap shows the correct state info and the Wikidata link on that page shows the correct timezone info.

Example coordinates.
35.0959f, -114.598f
35.115556f, -114.588611f