You have a pair of GPS coordinates, but your application needs more than a marker on a map. Perhaps you want to display the local time at a destination, label a weather observation, or help someone choose a time to call.
How do you turn latitude and longitude into a time zone?
There are two parts to the task: identify the time zone for the location, then use that zone to display the time for a particular date. Keeping those steps separate helps avoid common daylight saving time bugs.
What should a time zone lookup return?
Consider this coordinate pair in New York City:
Latitude: 40.7128
Longitude: -74.0060
The useful result is a named time zone such as America/New_York, together with the local time and UTC offset for the date you are checking.
These values describe different things:
| Value | Example | Meaning |
|---|---|---|
| Coordinates | 40.7128, -74.0060 |
The location on Earth |
| Time zone identifier | America/New_York |
The named zone used by date and time software |
| UTC offset | UTC−04:00 |
The difference from UTC at a particular instant |
| Local date and time | July 15, 2026, 8:00 AM |
How that instant is displayed in the selected zone |
The IANA Time Zone Database maintains rules for local time, including changes to UTC offsets and daylight saving time. A zone identifier lets software select the relevant rules; a fixed offset alone does not capture them.
Check a time zone without writing code
For an individual lookup, you can use the CoordMap latitude and longitude finder. I built this tool to bring coordinates and useful location details together in one place.
1. Enter the coordinates
Put 40.7128 in the latitude field and -74.0060 in the longitude field, then select Look up.
The negative longitude means west of the prime meridian. Dropping that minus sign selects a different location.
If your source uses degrees, minutes, and seconds or degrees and decimal minutes, the finder also accepts DMS and DDM input. Check that each value is assigned to the correct field.
2. Confirm the point on the map
Before using the time zone result, make sure the map shows the place you intended. Reversed coordinates or an incorrect direction letter can produce a valid-looking result for the wrong location.
You can also search for an address or select a point directly on the map.
3. Read the time zone details
The result panel shows the selected point's IANA time zone name, current local date and time, and current UTC offset when those details are available.
For a recognized time zone, a linked detail page is also available. Keep in mind that the displayed current offset describes the current date. A trip or appointment in another season may use a different offset.
Why dividing longitude by 15 is not enough
Earth rotates approximately 15 degrees per hour, so longitude can help estimate solar time. Civil time follows rules set by governments, and real time zone boundaries do not form a simple set of equal longitude strips.
This calculation therefore cannot reliably identify the legal time zone of a location:
// A rough geographic estimate, not a civil time zone lookup.
const estimatedOffsetHours = longitude / 15;
For an application, use a service or geographic boundary dataset that maps coordinates to named time zones. Then apply the rules for the date you need.
Display the result with JavaScript
Once you know the zone identifier, JavaScript's Intl.DateTimeFormat can display an instant in that zone:
function formatLocalTime(timeZone, instant = new Date()) {
if (!(instant instanceof Date) || !Number.isFinite(instant.getTime())) {
throw new TypeError("Provide a valid Date.");
}
return new Intl.DateTimeFormat("en-US", {
timeZone,
year: "numeric",
month: "short",
day: "numeric",
hour: "numeric",
minute: "2-digit",
hour12: true,
timeZoneName: "shortOffset",
}).format(instant);
}
const instant = new Date("2026-07-15T12:00:00Z");
console.log(formatLocalTime("America/New_York", instant));
// Example: Jul 15, 2026, 8:00 AM GMT-4
console.log(formatLocalTime("Asia/Tokyo", instant));
// Example: Jul 15, 2026, 9:00 PM GMT+9
Both lines display the same instant. The formatter changes its local representation according to the selected zone. Exact punctuation can vary between runtimes.
The Z in the input timestamp explicitly identifies UTC. You do not need to add an offset to the Date before formatting it.
See the MDN documentation for Intl.DateTimeFormat for additional formatting options.
Intl.DateTimeFormat does not accept latitude and longitude. You must resolve coordinates to a zone identifier separately. Also, resolvedOptions().timeZone reports the runtime's configured time zone, which may differ from the selected map location.
Check daylight saving time for the date you need
A location can keep the same named time zone while its UTC offset changes during the year.
For example, compare New York at two UTC instants:
const winter = new Date("2026-01-15T12:00:00Z");
const summer = new Date("2026-07-15T12:00:00Z");
console.log(formatLocalTime("America/New_York", winter));
// Example: Jan 15, 2026, 7:00 AM GMT-5
console.log(formatLocalTime("America/New_York", summer));
// Example: Jul 15, 2026, 8:00 AM GMT-4
For a scheduled event, retain its time zone identifier and calculate the display for the event date. Avoid reusing today's offset for every future date. Keep your runtime's time zone data current as rules can change.
What if you need an automated coordinate lookup?
For a backend integration, the Google Time Zone API accepts coordinates and a timestamp and returns a time zone identifier plus offset information.
Its request documentation specifies the coordinate order as latitude,longitude and the timestamp in Unix seconds. JavaScript's Date.now() returns milliseconds, so convert it with Math.floor(Date.now() / 1000).
Google's setup guide covers account and billing requirements, enabling the API, and configuring a key. Keep a server-side service key on your backend and restrict its use appropriately.
Handle unavailable results explicitly, particularly for points over water. Also check the provider's historical coverage: Google's documentation notes that its lookup does not account for a location having belonged to a different time zone in the past.
Common mistakes to avoid
-
Swapping latitude and longitude. Some map libraries use
[longitude, latitude]; a lookup service may expect the opposite order. -
Saving only an abbreviation. Labels such as
CSTcan be ambiguous. Retain the full zone identifier. -
Using the device's offset for a remote point.
getTimezoneOffset()describes the runtime's local zone for that date, not a selected coordinate. -
Applying the offset twice. Pass the original instant to
Intl.DateTimeFormatwith the target zone. - Treating current local time as a scheduling conversion. Converting an instant to local time is straightforward. Turning a user-entered local appointment into an instant also requires handling missing or repeated times around daylight saving transitions.
When building a location panel, give the time zone identifier, local date and time, and UTC offset separate labels. That makes the result easier to understand and helps users check that they are looking at the intended place and date.
Top comments (0)