A point in the ocean has a timezone
Coordinates in open ocean return a nautical timezone. Its Etc/GMT id has a backwards sign, but the offset field reads normally.
A coordinate lookup shouldn't need a nearby city just to answer what time it is. That matters on land near a timezone boundary, and it matters even more when the coordinate is in the ocean.
The Time API accepts the coordinates directly. This request asks about noon UTC on September 9, 2026, with optional detail included:
GET /time?lat=30&lon=-40&at=2026-09-09T12:00:00Z&deep=true
The response is:
{
"latitude": 30,
"longitude": -40,
"timezone": "Etc/GMT+3",
"at": "2026-09-09T09:00:00-03:00",
"unix": 1788955200,
"offset": "-03:00",
"abbreviation": "-03",
"dst": false,
"deep": {
"name": "GMT-03:00",
"offset_minutes": -180,
"offset_seconds": -10800,
"next_dst": null
}
}
The odd part is Etc/GMT+3. It means UTC minus three hours. Those timezone ids follow the older POSIX sign convention, so the sign reads backwards if you're used to UTC offsets. The offset and deep.offset_minutes fields use the familiar convention.
The local time and offset are returned without deep=true. Add it for the friendly name, numeric offsets, and next clock change, included on every plan. Without it, the deep field is omitted.
Over land, the lookup returns civil zones such as America/New_York. Open ocean uses nautical zones based on longitude. Both come back in the same response shape, and you can pass either id to /time/{timezone} afterward.
Keep ?at= when you need the offset at a particular instant. A civil zone's offset may change with daylight saving time. These nautical zones keep a fixed offset, but your application can read the same fields for both.