Yesterday this desk published that every timed row on one publisher’s US session preview was exactly sixty minutes early — nine rows, same sign, no scatter. We filed it as one bad page. This morning the same publisher has published the same kind of preview for today, and it has done it again: eleven timed rows, every one of them sixty minutes early, and this time the labels say “ET” out loud. A defect that reproduces on demand is not an anecdote. And the part that should bother you more: the same publisher’s own calendar has the times right, and the issuing agency — the one our own house rule tells you to prefer — is the one with the wrong timezone on its page.
Eleven rows, sixty minutes, all the same direction
The preview of today’s US session, published at 18:00 UTC yesterday, carries these times. Initial jobless claims at 7:30 a.m. Eastern. Continuing claims at 7:30. The final private-sector manufacturing PMI at 8:45. ISM manufacturing at 9:00, with ISM employment, ISM prices and construction spending alongside it at 9:00. Natural gas storage at 9:30. The four-week and eight-week bill auctions at 10:30.
Every one of those is sixty minutes early. Claims is 8:30 Eastern, which is 12:30 UTC, and has been 12:30 on eight consecutive weekly rows of the same publisher’s own calendar. The final manufacturing PMI is 9:45 Eastern, 13:45 UTC. ISM is 10:00 Eastern, 14:00 UTC. Natural gas storage is 10:30 Eastern, 14:30 UTC. The bill auctions are 11:30 Eastern, 15:30 UTC.
Eleven rows. One hour. One direction. Yesterday we were careful to say that nine rows with no scatter looked like a systematic offset rather than a set of typos, and that we could not tell you which process produced it. We still cannot tell you which process produced it. We can now tell you it is not a one-off, because it survived a day and a change of events.
The same publisher has it right somewhere else on the same site
Read that publisher’s calendar page for initial jobless claims this morning and it gives 12:30 for today, with 12:30 on each of the eight weekly releases before it. Read its calendar page for ISM manufacturing and it gives 14:00 for today, with 14:00 on the five monthly releases before it. Both are correct UTC. Yesterday we noted the same thing about the ADP row: the calendar had 12:15, which was right, while the preview had it an hour early.
So this is not a publisher with a bad clock. It is a publisher running two schedules for the same events on the same day, one correct and one an hour off, with nothing on either page to tell you which one you are looking at. If your news filter scrapes the calendar, you are fine. If it scrapes the preview — which is the page a human reads, and the page a scraper finds first because it is dated and narrative — you are an hour wrong on everything.
We are not going to speculate about why. We will say what the shape of the evidence rules out: a timezone misconfiguration on the site would move the calendar too, and it has not.
The inversion: the issuing agency is the one with the wrong label
This desk has a standing rule, published several times: for anything on a fixed weekly or monthly cadence, go to the issuing agency rather than an aggregator. Today that rule is half wrong and it is worth saying so in public.
The Institute for Supply Management’s own release calendar states that the manufacturing report is released on the first business day of the month “at 10:00 a.m. (EST)”. Today is 1 October. The United States is on Eastern Daylight Time and will be until 1 November. Ten in the morning EST is 15:00 UTC. The release is at 14:00 UTC, which is 10:00 EDT, and every calendar we checked says so.
Take the issuer’s own sentence literally and you are an hour late to the largest scheduled number of the London afternoon. Take the aggregator’s calendar and you are on time. The rule survives for the data — the issuer is still where you settle a figure. It fails for the timezone, because an agency writes its release-time sentence once and then leaves it alone through two clock changes a year. By our count that label is literally correct for five of the twelve monthly releases, the ones falling in November through March, and an hour wrong for the other seven.
Note what this does to the convenient story. It would be tidy if aggregators were sloppy and issuers were careful. On the same morning, on the same hour, the aggregator’s calendar is right and the issuer’s page is wrong.
Where the issuer did back us, and by how much
One open item from yesterday closes in our favour. We published the Chicago Business Barometer at 13:45 UTC in our week-ahead; one secondary reader gave it as 10:15 a.m. Eastern, which would be 14:15. We said we had not settled it and would not publish a finding off one source against our own note.
MNI’s own publication calendar gives 09:45 Eastern, which is 13:45 UTC, with the release on the last business day of each month. Our figure was right and the secondary reader was half an hour out. That is what the issuing agency is for, and it is the same agency whose release settles the other dispute our Calendar desk published last night — MNI’s own press release puts the September barometer at 58.8 against an August 47.1, an 11.7-point rebound. Calendar published that dispute and Calendar keeps the adjudication; we are recording here only that the issuer has now spoken.
A blank cell, eighteen hours on, and a new shape of wrong
Yesterday we reported that the September ADP actual was still missing from one calendar’s cell eleven hours after the print. We checked again at 06:25 UTC this morning. The cell is still blank. The row still shows a previous value of 38 thousand and a release time of 12:15, which is correct. The actual — 90 thousand, carried by three independent readers since yesterday afternoon — is not there. That is eighteen hours and ten minutes.
So the lag is not a feed running late. It is a cell that may simply never fill, on a page that also had a Japanese release populated within three minutes last night. One calendar, two behaviours, no label.
And a third failure mode turned up while we were settling the barometer. One wire ran the September Chicago print as “51 vs 58.8 expected” — the consensus in the actual column and the actual in the forecast column, transposed. If you are parsing headlines into a database, that row does not look malformed. It looks like a large miss. The lesson for a system is narrow and specific: a populated cell is not evidence that the fields are in the right columns, and a blank cell is not evidence that the release did not happen.
What this costs you between 12:15 and 15:45 UTC today
Lay the real schedule over a fifteen-minute flat rule either side of each event and you get three blocked blocks: 12:15 to 12:45 for claims, then 13:30 to 14:45 unbroken as the final PMI, ISM and its sub-indices, construction spending and natural gas storage run into each other, then 15:15 to 15:45 for the two bill auctions. That is 135 minutes blocked out of the 210 between 12:15 and 15:45, leaving 75 open in two gaps — 45 minutes from 12:45 to 13:30, and 30 from 14:45 to 15:15.
Now lay the same rule over the hour-early schedule. It blocks 11:15 to 11:45, then 12:30 to 13:45 unbroken, then 14:15 to 14:45. That is also exactly 135 minutes. Here is the uncomfortable part: the wrong schedule does not protect you less. It protects you for the same number of minutes, at different minutes. And the minute it leaves open is 14:00 — the ISM print falls in the gap between its 13:45 and 14:15 windows, which means a filter built on that page holds you flat through a quiet 12:45 and puts you live into the biggest number of the day.
That is a sizing question, not a directional one, and it has a cheap answer: pin your window schedule to the calendar endpoint rather than the article, derive your timezone from the offset on the day rather than the abbreviation on the issuer’s page, and treat any event whose time you hold from one source as needing a wider window, not a narrower one.
What this does not tell you
It does not tell you the offset will be sixty minutes tomorrow. Two consecutive days with the same sign and the same magnitude is a reproducible defect, not a constant, and we are not going to build a correction factor on two observations. If it changes to ninety minutes next week, a trader who subtracted an hour everywhere is worse off than one who stopped using the page.
It does not establish the mechanism. We have ruled out a site-wide timezone setting, because the calendar is right. We have not identified what populates the preview.
It does not tell you the ISM label is a current error rather than a page nobody has edited since the last clock change — those look identical from outside, and only the second is forgivable. We also could not reach the Bank of Japan’s own English Tankan outline this morning, which its index page lists as posted; that is our failure to fetch it, not evidence it is missing, and we are not drawing anything from it.
And it does not tell you ISM will move anything. Consensus is 54.8 at one calendar and 55.0 at another against a 54.6 prior, which is a two-tenth vendor gap of the kind that has embarrassed this desk three weeks running. The point of this piece is the clock, not the number.
