Skipped hours, repeated hours and how social media schedulers handle time zones

How do social media schedulers handle time zones?

Under the hood, how social media schedulers handle time zones comes down to one rule: keep the wall-clock time the person chose together with the IANA zone name they chose it in, and turn that pair into a UTC instant only when a platform API needs a timestamp. "9:00 in America/New_York on 15 July" is the intent. 2026-07-15T13:00:00Z is what the API receives.

The zone name matters because it carries the rules. The IANA Time Zone Database, which IANA describes as containing "the history of local time for many representative locations worldwide", is "updated periodically to reflect changes made by political bodies to time zone boundaries, UTC offsets, and daylight-saving rules." The release listed on iana.org when this page was written was 2026d. A name like Europe/Berlin points at those rules. An offset like +01:00 points at nothing and goes stale twice a year.

Every other design choice follows from that split between intent and instant. The rest of this page covers where each half breaks.

Why is a fixed UTC offset the wrong thing to store?

A fixed offset records what the clock said on one day and assumes it holds forever. Store 9:00 New York time in January as 09:00-05:00, reuse that offset for a July post, and the post lands at 2026-07-15T10:00:00-04:00. That is 10:00 local, one hour late, because New York runs on UTC-4 in summer.

RFC 9557, the IETF document that adds bracketed zone names to RFC 3339 timestamps, warns against exactly this. It calls offset time zones "strongly discouraged" and says programs "MUST NOT copy the UTC offset from a timestamp into an offset time zone." Its own example shows why: 2020-01-01T00:00+01:00[Europe/Paris] lets a program add six months and land on the correct summer time, while the same calculation on 2020-01-01T00:00+01:00[+01:00] "will produce an incorrect result that will be off by one hour in the time zone Europe/Paris."

The same bug hides in recurring posts. A weekly slot saved as "every Monday 08:00 UTC" drifts by an hour for everyone outside UTC when their clocks change. A slot saved as "every Monday 08:00 Europe/London" does not.

What happens to a post scheduled in the skipped hour?

It points at a time that never exists, and the scheduler has to pick a real one. In 2026, New York moves its clocks from 02:00 to 03:00 on 8 March, at 07:00Z. Nothing between 02:00 and 02:59 happens on that date. A post booked for 02:30 has no matching instant.

The JavaScript Temporal API makes the choice explicit through its disambiguation option, which takes "compatible", "earlier", "later" or "reject". MDN documents the default like this: "compatible (default): Same behavior as Date: use later for gaps and earlier for ambiguities." Under "compatible", 02:30 becomes 03:30 EDT, which is 07:30Z. Python's zoneinfo gives the same instant for fold=0 and 06:30Z, one hour earlier, for fold=1.

"reject" is the honest choice for a scheduling UI. Refuse the slot and tell the person that 02:30 does not exist that night, rather than quietly moving their post. For a background job that must fire no matter what, "compatible" is the least surprising rule, and it matches what Date already does.

What happens in the repeated hour?

The same wall-clock time happens twice, and the scheduler has to pick one. On 1 November 2026, New York falls back from 02:00 EDT to 01:00 EST at 06:00Z, so 01:30 occurs once at 05:30Z and again at 06:30Z. The UNIX timestamps are 1793511000 and 1793514600, exactly 3,600 seconds apart.

MDN's rule for "compatible" is "earlier for ambiguities", so a Temporal-based scheduler posts at the first 01:30. Python's zoneinfo does the same for fold=0. Either way the rule has to live in code, because nothing in "01:30 America/New_York" says which of the two instants the person meant. A calendar that shows both options on that one night avoids the guess.

Why do the US and Europe gaps matter for global posting?

The two regions change clocks on different dates, so the gap between them is not constant. In 2026, London and Berlin spring forward on 29 March at 01:00Z, three weeks after New York. From 8 March to 29 March, New York is four hours behind London instead of five. In autumn, Europe falls back on 25 October and New York on 1 November, which opens another week at four hours.

These dates come from the tz database, not from a rule of thumb. A scheduler that hardcodes "London is New York plus five" posts an hour off for four weeks a year. One that converts each post through its own zone name gets all four weeks right without special cases. This matters most when one campaign goes out to several regions at their local best time to post on social media.

What time formats do platform APIs accept?

Every platform API that takes a future time wants an absolute instant: a UNIX integer or an ISO 8601 or RFC 3339 string with an offset or a Z. None of them takes an IANA zone name. The table covers the scheduling fields each platform's own docs describe.

Two details from that table catch people out. Meta's Pages API guide spells the standard "ISO 8061", a typo for ISO 8601 on the page that defines the field. And Facebook Reels accept only the integer form, so a scheduler that sends ISO strings to /feed needs a separate code path for Reels.

Bluesky is a special case. It has no scheduling field, but every post record carries a required createdAt, which the lexicon describes as a "Client-declared timestamp". The atproto spec says "Timezone specification is required" and "It is strongly preferred to use the UTC timezone, and to represent the timezone with a simple capital Z suffix." A queued Bluesky post should get its createdAt at send time, not at the moment it was drafted.

Does any platform API accept a time zone name?

No. None of the platform scheduling docs covered here accepts a string like America/New_York. The conversion from zone name to instant is always the scheduler's job, and the platform never sees the zone.

Facebook comes closest to doing the conversion itself, and that is the risky part. Meta's guide accepts relative strtotime() strings such as +2 weeks and tomorrow, but it does not say which zone "tomorrow" is resolved in. Meta's own advice is that "If you are relying on strtotime()'s relative date strings you can read-after-write the scheduled_publish_time of the created post to make sure it is what is expected." A scheduler that sends a computed UNIX timestamp never needs that check.

RFC 9557 does define a place for a zone name, as a bracketed suffix: 2022-07-08T00:14:07+01:00[Europe/Paris]. None of the scheduling endpoints above documents support for that suffix, so strip it before sending. The per-platform detail for two of these fields sits in the Mastodon scheduled_at lead time rules and every YouTube publishAt field and its failure modes.

What should a scheduler store for each post?

Three things: the local wall-clock time, the IANA zone name, and the UTC instant derived from them. The first two are the source of truth. The third is a cache for the queue to sort and fire on.

The reason to keep the local time is that zone rules change after you schedule. MDN puts it plainly: "if you store a time in the future, with an anticipated offset, then before that time comes, the time zone definition may have changed due to political reasons." When a tz database update ships, recompute the UTC instant for every future post from its wall time and zone. A system that stored only UTC cannot do that, because it no longer knows what the person asked for.

The other half is the send path. Convert to the format each API wants at dispatch: an integer for Facebook Reels, Z-suffixed ISO for YouTube and Mastodon, whole minutes for X Ads. Check the result against the platform's minimum lead time before sending. Mastodon rejects anything within 5 minutes, and Facebook rejects anything within 10. Getting those checks right is most of what separates a reliable queue from one that schedules social media posts at the wrong hour twice a year.

Frequently asked questions

Should a social media scheduler store times in UTC?

Store the UTC instant for sorting and firing, but not as the only record. Keep the wall-clock time and the IANA zone name too, so the instant can be recomputed when the tz database changes a zone's rules. MDN notes that a zone's definition "may have changed due to political reasons" before a future time arrives.

What is an IANA time zone name?

It is an identifier from the IANA Time Zone Database, such as America/New_York, Europe/London or Asia/Tokyo. Each name points at the full history of UTC offsets and daylight saving rules for that location. IANA describes the database as "updated periodically to reflect changes made by political bodies".

What happens if I schedule a post at 2:30 AM on the night clocks spring forward?

In New York on 8 March 2026, 02:30 does not exist. Under Temporal's default "compatible" rule the post moves forward to 03:30 EDT, 07:30Z. With "reject" the scheduler throws a RangeError instead, which lets the UI ask the person to pick another time.

Does Facebook's scheduled_publish_time accept a time zone?

Only as an offset inside an ISO 8601 string, such as 2018-09-01T10:15:30+01:00, which is Meta's own example. It also accepts a UNIX timestamp in seconds and strtotime() strings. Meta's guide does not say which zone relative strings like tomorrow resolve in, and it recommends reading the value back to check.

Which format does the YouTube API want for publishAt?

Google's videos resource says status.publishAt "is specified in ISO 8601 format." Send a full date and time with a Z or an explicit offset. Google documents that a past value publishes the video "right away", so a conversion bug that pushes the time into the past makes the video go live at once instead of returning an error.

Why are my scheduled posts an hour off after daylight saving time ends?

The usual cause is a stored fixed offset. A post saved as 09:00-04:00 in summer still fires at 13:00 UTC after the clocks change, which is 08:00 in New York in winter. Storing America/New_York with the wall time and recomputing the instant fixes it.

What happens to a post scheduled for 1:30 AM when the clocks fall back?

On 1 November 2026, New York repeats 01:00 to 01:59, so 01:30 happens at 05:30Z and again at 06:30Z. Under Temporal's default "compatible" rule, and Python's zoneinfo with fold=0, the post goes out at the first one. The rule has to live in the scheduler's code, because "01:30 America/New_York" does not say which instant the person meant.

Why is New York only four hours behind London some weeks of the year?

The US and Europe change clocks on different dates. In 2026 New York springs forward on 8 March and London on 29 March, so in between New York is four hours behind London instead of five. Autumn opens another four-hour week, from 25 October when Europe falls back to 1 November when New York does.

Can you schedule a post through the Instagram or LinkedIn API?

In the docs this page covers, the create endpoints for Instagram, Threads, LinkedIn, TikTok, Pinterest and X API v2 have no future-time field. Facebook, YouTube, Mastodon and X Ads do have one. For the first group, the scheduler has to hold the post and send it when the time arrives.

What timestamp should a Bluesky post carry?

Bluesky has no scheduling field, but every post record needs a createdAt, which the lexicon describes as a "Client-declared timestamp". The atproto spec requires a timezone and strongly prefers UTC with a capital Z suffix. A queued post should get its createdAt at send time, not when it was drafted.