Twice a year, a predictable wave of confusion arrives. Automated posts that had been landing at eight in the morning start landing at seven, or nine. Nothing was changed. Nobody touched a setting. The schedule simply moved, and it moved for everyone using that particular combination of server, feed and audience.
The cause is almost never the posting tool. It is the interaction between three separate clocks — the one in your content management system, the one in the feed’s timestamps, and the one your schedule is expressed in — and the fact that daylight saving moves some of them and not others.
This guide explains where each clock comes from, why the drift happens, and how to set things up so a schedule stays correct through the whole year without anyone adjusting it twice annually.
Understanding this is most of the fix, because once you can name which clock moved, the correction is obvious.
Your content management system has a configured time zone. When you schedule a post for nine in the morning, that nine is in the CMS’s zone. WordPress calls this the site timezone, and it can be set either as a named region or as a fixed offset — a distinction that matters enormously, as explained below.
When the CMS generates a feed, it writes each item’s pubDate with an offset attached, for example +0000 lub +0300. That offset is supposed to describe the same moment in a form anyone can interpret.
Your publishing window — “post between nine and eight” — is expressed in some zone too. If that zone is not the same as your audience’s, or not the same as the feed’s, the two drift apart whenever either one changes.
When all three agree, everything is invisible and nobody thinks about it. Drift appears when one of them observes daylight saving and another does not.
This is the single most useful distinction in the whole subject, and it is where most sites get it wrong.
A named zone — Europe/Vilnius, America/New_York — describes a place. It carries its own rules about when daylight saving starts and ends, and those rules are updated when governments change them. A site configured this way follows local time automatically, forever.
A fixed offset — UTC+2, UTC-5 — describes a constant difference from universal time. It never changes. It knows nothing about daylight saving and cannot, because an offset is not a place.
The consequence is direct. A site set to UTC+2 in winter will be an hour out all summer, because the place it is meant to represent moved to UTC+3 and the setting did not. Everything that site publishes carries a timestamp that is consistently, invisibly wrong for half the year.
| Named zone | Fixed offset | |
|---|---|---|
| Example | Europe/Vilnius | UTC+2 |
| Follows daylight saving | Yes, automatically | No, ever |
| Survives a law change | Yes, via updated data | No |
| Correct all year | Yes | Only half of it, in DST regions |
| Recommended for | Almost every site | Servers and logs only |
If you take one action from this article, make it this: check whether your site’s timezone is set to a region or to an offset, and change it to the region.
A wrongly configured offset does not produce an error. The feed is valid, the dates parse, the posts appear. Nothing logs a warning, because nothing is technically malformed — the timestamps are simply describing a different moment from the one you meant.
That is why the problem surfaces as “our posts moved an hour” rather than as a failure, and why it always surfaces on the last Sunday of March or October rather than on the day somebody changed a setting. The setting was wrong the whole time; daylight saving merely made it visible.
It is also why the instinct to fix it by adjusting the schedule by an hour is a trap. That correction makes the current half of the year right and guarantees the other half will be wrong.
There is a correct answer, and it is not the one most people choose.
Schedule in your audience’s time, not your own. A publisher in one country with readers in another should set windows around the readers’ waking hours. The question a schedule answers is “when will this be read”, and the reader’s clock is the only one that bears on it.
Where the audience spans several zones, pick the largest. Trying to satisfy three continents with one window produces a schedule that suits none of them. If two regions genuinely matter, run two destinations with two windows rather than compromising on one.
Keep the feed in UTC if you control it. Feeds are read by machines, and UTC removes every ambiguity. Convert to local time at the point of display or scheduling, never in the data itself. This is standard practice for the same reason databases store UTC.
The combination that causes fewest problems is: site timezone set to a named region, feed timestamps emitted in UTC with an explicit numeric offset, and publishing windows expressed in the audience’s zone.
A detail worth knowing if your audience is international: large parts of the world do not observe daylight saving at all, and among those that do, the changeover dates differ.
Europe and North America change on different weekends, which produces a two- or three-week window each spring and autumn when the usual difference between them is one hour off its normal value. A schedule tuned to “three in the afternoon our time is nine in the morning theirs” silently stops being true for those weeks.
The southern hemisphere shifts in the opposite direction from the northern, so the gap between, say, Europe and Australia changes twice by two hours rather than moving in step. And many countries have abolished the practice, or changed their rules, in the past few years.
None of this needs memorising. It needs one habit: express times in named zones and let the software resolve them, rather than doing arithmetic with offsets yourself.
When posts are landing at the wrong hour, four checks in this order will find the cause almost every time.
Check the site’s timezone setting. Is it a region or a fixed offset? If it is an offset, that is very likely your answer, and no further investigation is needed.
Open the feed and read a timestamp. Does the item’s pubDate match when the article actually went live, and does it carry a numeric offset? A date with GMT or a zone abbreviation instead of +0000 is ambiguous and may be interpreted differently by different readers.
Compare the publication time with the posting time. If the gap is consistently a whole number of hours, it is a zone problem. If it varies, it is a caching or polling-interval problem instead — a different issue entirely, and one covered under feed troubleshooting.
Check the server’s own clock. Rare, but a host with a misconfigured system time produces feeds that are wrong in a way nothing else will reveal.
The abstract version convinces nobody, so here is how it actually unfolds.
A publisher in Lithuania schedules its main article of the day for 08:00, aimed at readers commuting to work. The site’s timezone was configured years ago as UTC+2, which was correct at the time it was set, in December.
Through the winter everything is right. On the last Sunday of March the country moves to UTC+3, but the site setting does not, because a fixed offset cannot. From that morning on, the article that is meant to land at 08:00 local lands at 09:00 local — after the commute, into a quieter hour.
Nobody notices for three weeks, because nothing broke. Eventually someone observes that morning engagement has fallen and assumes the audience has changed, or that the algorithm has. The actual cause is a one-hour shift that happened on a specific Sunday and will reverse itself in October, at which point the numbers will recover and nobody will know why.
The instructive part is what happens next. The obvious fix — move the schedule to 07:00 — makes the summer correct and guarantees the winter will be wrong. The publisher then has a schedule that needs adjusting twice a year and a note somewhere explaining which direction to adjust it in, which will be lost within eighteen months.
Changing one setting from UTC+2 to Europe/Vilnius resolves it permanently, including for future rule changes nobody has announced yet.
Publishers with genuinely international audiences hit a limit that no single schedule can solve, and it is better to recognise it early than to keep tuning one window.
The arithmetic is unforgiving. A window that lands mid-morning in Central Europe lands before dawn on the American west coast and late evening in eastern Australia. There is no hour that is reasonable in all three, which means a single schedule is always choosing one audience and accepting the others as collateral.
The workable arrangement is one destination per region, each with its own window expressed in that region’s named zone, all fed by the same source. The content is written once; only the release timing differs. Where two regions matter roughly equally, this doubles the number of destinations and changes nothing else about the setup.
What to avoid is the compromise window — picking an hour that is mediocre everywhere on the theory that it is fair. Fairness is not a metric anybody reports on, and the result is usually worse than simply serving the largest audience well and letting the others catch up asynchronously.
Three practical rules produce a schedule that does not need seasonal attention.
Set the site to a named region and leave it. This alone fixes the majority of cases permanently.
Use windows rather than exact times. “Between nine and six” absorbs an hour of drift without anybody noticing. “At 09:00 exactly” does not, and turns every clock discrepancy into a visible problem.
Do not compensate manually. If you find yourself shifting a schedule by an hour twice a year, you have a configuration fault that is being papered over. Fix the zone setting and remove the compensation, or you will eventually forget which direction you adjusted in.
For automated publishing specifically, these rules matter more than for manual posting, because nobody is watching. A person posting by hand notices immediately that it is dark outside; a schedule does not.
Daylight saving started or ended, and something in the chain is configured with a fixed offset rather than a named zone. The setting was wrong before the changeover too; it only became visible then.
A city or region, always. A fixed offset cannot follow daylight saving and will be wrong for half of each year in any region that observes it.
UTC with an explicit numeric offset, for example +0000. Avoid zone abbreviations, which are ambiguous and not universally recognised.
The largest audience’s. If two regions genuinely matter, run separate destinations with separate windows rather than compromising on a single one.
It works but hides the fault, and it is easy to forget or to adjust in the wrong direction. Fixing the zone setting removes the need entirely.
No. Europe and North America change on different weekends, the southern hemisphere moves in the opposite direction, and many countries do not observe it at all.
Yes. A consistent whole-hour gap points at zones; a variable gap points at feed caching or the polling interval instead.
Posts drifting by an hour is not a scheduling failure. It is three clocks that were never quite in agreement, and daylight saving pulling them far enough apart to notice.
The fix is almost always one setting. Set your site’s timezone to a named region rather than a fixed offset, and the CMS will follow local time correctly forever, including through future rule changes that have not happened yet.
After that, keep feed timestamps in UTC with numeric offsets, express publishing windows in your audience’s time rather than your own, and use ranges instead of exact minutes so an hour of slack never becomes a visible problem. Do those four things and the twice-yearly confusion stops arriving — permanently, and without anyone having to remember which weekend it falls on.
