Keeping 09:00 publish times consistent across DST changes

Tools of the trade
1

  1. Start with the time the person actually chose. A spreadsheet cell containing 09:00 is incomplete: it needs a date and an intended publishing timezone, such as Europe/Paris. Keep that timezone with the post even after converting the time for other tools. Otherwise, a spreadsheet export can turn a local publishing time into an unlabeled value that the next tool interprets differently.

  2. Convert that date and local time to a UTC timestamp before handing it to the scheduler. Store both values: the UTC timestamp is the canonical instant to enqueue, while the named timezone explains what the author intended. Avoid storing only a fixed offset, because the offset changes with daylight saving time.

  3. Check dates around the transition before enqueueing. For example, 09:00 in Paris on October 20, 2026, is 07:00 UTC; 09:00 in Paris on October 27 is 08:00 UTC. Both posts should still display as 09:00 locally. A time inside the clock-change hour needs an explicit decision: it may occur twice in autumn or not exist in spring. Flag those rows rather than guessing.

  4. Compare the scheduler’s preview and the platform’s displayed publish time against the intended local time, not just against each other. Tools may label or convert times differently. Log the spreadsheet value, timezone, UTC timestamp, and displayed time for any mismatch; that gives you a specific conversion step to fix.

How do you keep the intended local time consistent when a post moves between your spreadsheet, scheduler, and platform?

2

The UTC timestamp is the right enqueue instant for a one-off post. A recurring schedule needs a different source of intent: retain each occurrence’s local date and time plus its named timezone, then calculate that occurrence’s UTC timestamp using current timezone rules. Reusing a previously calculated UTC timestamp may shift the intended local time if those rules change.

3

After a timezone-database update, recalculate future queued occurrences from their retained local date, local time, and named timezone. Replace any queued UTC timestamp that changes, since rules may have changed after those jobs were first calculated; leave already-published occurrences untouched.

4
  1. Recalculating queued occurrences after a timezone-database update is right. Reconcile by occurrence ID: update a pending job only if its recalculated UTC instant differs, using a version check so concurrent reconciliations cannot overwrite each other.
  2. Exclude jobs already claimed for dispatch. Keep the publish operation idempotent by occurrence ID so a timestamp change cannot trigger a second publish.