Use cases

Scheduling social posts for every time zone at once

Posting at nine in the morning works well for exactly one time zone and poorly for everyone else. A media brand with a following spread across five continents had been scheduling everything around its own headquarters time, which meant a meaningful share of its audience saw every post either as the first thing in the morning, in the middle of the workday, or well after midnight, largely at random depending on where they happened to live.

The team already had rough location data for its audience, pulled from where engagement was coming from, city and country level, gathered from server logs rather than from a tracking script. What it needed was to convert that location data into an actual local time it could schedule around, since a country like Brazil or the United States can span more than one time zone, and posting decisions made at the country level were still often wrong for individual cities within it.

For each major audience cluster, the team resolved a representative coordinate and sent it to /v1/timezone, which returns the IANA time zone name and current UTC offset for that point. Because the endpoint accepts a specific moment to calculate the offset for, not just the current time, the team could plan a full week of posts and get the correct offset for each day even across a daylight saving transition, rather than assuming a fixed offset that would drift out of sync partway through the schedule.

With accurate local time for each audience segment in hand, the posting calendar stopped being one schedule and became several, staggered so that a piece of content hit each region during that region's own high-engagement hours rather than all firing from a single master schedule built around headquarters time. The brand did not need to post more content to see the benefit. The same volume of posts, timed correctly, reached more of the audience while people were actually looking at their feeds.

The team also used the same lookup for something smaller but persistent: correctly labeling event times and livestream announcements. A launch announced as "8 PM" without a time zone attached had generated a steady trickle of confused replies for years. Attaching the resolved local time zone to every scheduled announcement, and letting the platform display it correctly for each viewer's own settings, closed off a small but constant source of avoidable confusion.

None of this required tracking individual followers or their devices. The location data came from aggregate, server-side engagement patterns the brand already had, and the timezone lookup itself ran a handful of times per week, once per audience cluster, a volume so light it barely registered against the free daily allowance included with the account's key.

Getting posting times right is a small change with a compounding effect, since every post benefits from it rather than needing a one-time fix. Documentation for the endpoint, including how a specific moment can be passed in, is at /docs/timezone-lookup/.