Scheduling social posts for clients in other time zones
When the agency is in one time zone and the client's audience in another, "post at 9" needs a rule. How to pick the right clock, name time zones properly and survive daylight saving changes.
An agency in Manchester running social for a bakery in Chicago has two clocks on the wall, and every scheduled post depends on which one someone was looking at. Most of the time the mistake is small: a post goes out an hour early or late. Occasionally it is not: a “doors open at 9” announcement lands at 3 a.m. local time, or a sale post goes live after the sale has ended. This guide sets out a simple rule for whose time to use, how to name time zones so software cannot misread them, and the daylight saving traps that catch teams twice a year.
Use the audience’s clock, not yours
The rule that prevents most problems is short: every time in a client’s plan is the client’s local time. That is the clock their customers live by, the clock their opening hours, events and offers refer to, and the clock the client thinks in when they approve a post.
Writing times in the agency’s own time zone feels convenient for the person scheduling, but it moves the conversion into everyone’s head. The writer converts when drafting, the client converts back when reviewing, and the account manager converts again when a date moves. Every conversion is a chance to be wrong.
There are two exceptions worth agreeing explicitly:
- Audiences spread across regions. A software company selling across North America may want posts timed for the East Coast morning even though its office is in Denver. Pick one reference time zone per client, write it down and use it everywhere.
- Live moments. A product launch at a fixed global instant, or a webinar, is one moment everywhere. Schedule it once at the correct instant and state the time in the caption with its time zone (“today at 16:00 CET”).
Name time zones properly
“EST”, “CET” and “IST” are labels, not time zones. IST can mean India, Ireland or Israel; EST is only correct for part of the year, because New York switches to EDT in summer. Abbreviations also say nothing about when daylight saving starts or ends.
Software uses time zone names from the IANA Time Zone Database instead: identifiers such as America/Chicago, Europe/London or Asia/Kolkata. The database holds “the history of local time for many representative locations worldwide”, including daylight saving rules and changes to UTC offsets, and it is updated whenever governments change their rules (IANA Time Zone Database). When you set up a client in any scheduler, choose the city-based name, not an offset like “UTC−6”. An offset is right for half the year at most.
Governments do change these rules, sometimes with little notice. At the time of writing, IANA’s release notes record that Manitoba moves to permanent −05 on 31 October 2026 (IANA Time Zone Database). Software that uses the named zone picks up such changes through normal updates; a fixed offset typed into a spreadsheet does not.
The daylight saving traps
The gap between two countries is not constant
Countries change their clocks on different dates. In the UK, clocks go back one hour at 2 a.m. on the last Sunday in October (GOV.UK). In the United States, daylight saving time ends at 2 a.m. on the first Sunday of November (NIST). In 2026 that means London changes on 25 October and New York on 1 November. For that one week the gap between the two cities is four hours instead of five. The same thing happens in spring, when the US moves its clocks on the second Sunday of March and the UK on the last Sunday of March.
If your team converts times by hand with “Chicago is six hours behind”, every post in those weeks is an hour off. Let the software convert, using named time zones.
Some places do not change at all
Not every region observes daylight saving. NIST lists Hawaii, American Samoa, Guam, Puerto Rico, the Virgin Islands and Arizona as not observing it, with the Navajo Nation within Arizona as an exception that does (NIST). A Phoenix client and a Denver client share a clock in winter and not in summer. This is exactly the difference between America/Phoenix and America/Denver.
Times that do not exist, and times that happen twice
On the night clocks go forward, the hour between 2 and 3 a.m. (in the US) simply does not happen. On the night they go back, an hour happens twice. Few social posts are scheduled at 2:30 on a Sunday morning, but automated or overnight posts sometimes are. Keep scheduled posts out of that hour on change weekends, and check any recurring overnight slot.
Plans made before the change, published after it
A post planned in September for a November slot is the classic case. If someone wrote the time as an offset, or converted it by hand in September, it will be wrong after the clocks change. If the time was entered as local time in a named time zone, it stays correct.
A routine for multi-time-zone agencies
- Record each client’s time zone at onboarding as an IANA name, next to their opening hours and approver.
- Show the time zone on every planning document. Put “All times America/Chicago” at the top of the client’s content calendar sheet and in the approval request.
- Never convert by hand. If you need to know your own local equivalent, let a calendar app or the scheduler show it.
- Mark the change weekends for every region you post in, at the start of the year. Review scheduled posts in those weeks.
- Write times in captions with their zone when the audience is spread out (“Live at 12:00 ET / 9:00 PT”).
- Think in the audience’s day, not the clock. “Before the morning commute” and “after the kids are in bed” travel better between time zones than “9:00”.
- Re-check after a client moves. If a client changes headquarters or market focus and you change their time zone setting, review the posts already scheduled.
What about the best time to post?
Time zones decide when a post goes out; they do not decide when it should. Generic “best time to post” lists are averages over other people’s audiences. Your client’s own numbers are a better guide: compare posts that went out at different times of day over a few months, keeping the type of content similar, and see whether a pattern holds. The engagement rate calculator helps keep those comparisons consistent.
Doing this in PostRoost
Each PostRoost client has its own time zone, set under Accounts & settings as a named time zone. Every time you pick in the composer, read on the content calendar or enter in a bulk upload sheet is that client’s local time, so a writer in another country schedules “10:00” and the post goes out at 10:00 where the client is. The calendar itself is shown in the client’s time zone, and analytics attribute numbers to the client’s day the post went live.
Because times are stored against the client’s named time zone rather than a fixed offset, daylight saving changes are handled by the time zone rules. Agencies with clients in several regions keep each one separate, with its own calendar, accounts and approver. How scheduling works.
