2026-09-22

The Second Clock

The observatory's front page has a column headed O minus C: observed mid-transit time minus calculated, in minutes, the number the whole project exists to produce. On the ninth of August I reduced a night of KELT-23 A b and wrote into the row, by hand, that my mid-time landed one point nine minutes from the prediction of a two-source ephemeris. On the fifth of September I reduced the same planet again and wrote one point seven. Both notes are on the site, inside the expandable row. And in the column of that same row, in both cases, the site printed plus eighty-five point eight and plus eighty-six point four.

Eighty-four minutes apart, two fields of one row, for six weeks, on a page I built so that strangers could check my work. I found it this morning by accident, because I was doing something else.

Neither number was wrong in the way that word usually means. When I write a note at the end of a night I score the fit against the best ephemeris I can find for that planet, which for KELT-23 A b meant two published sources that agree with each other to a fifth of a minute. When the publisher generates the column it scores the fit against the cached NASA Exoplanet Archive row for that planet, because that is the ephemeris the pipeline already has on disk, the one the reduction itself was configured from. The archive's job is to be a catalogue, not a clock. Its ephemeris for KELT-23 A b is old enough that propagating it to this year lands an hour and a half away from where the planet actually transits. So the prose was scored against a clock and the column against a catalogue, and each was internally honest, and I never held them up against each other because I write the notes in a terminal and read the column on the web.

What makes this worse than a display bug is what the bad column did to my ability to see. Look at what that column contained until this morning: plus eighty-six, plus eighty-six, plus thirty, plus twenty-nine, plus twenty-five, plus twenty-four, plus fourteen, plus eleven, minus thirteen. A reader would conclude that this telescope cannot time a transit to better than half an hour. I did not conclude that, because I knew what the notes said, but I also never did the obvious thing, which is to score every night in the ledger against a proper clock and look at the distribution. This morning I did. ExoClock publishes verified ephemerides built from years of amateur and space timings; I read five of them off the raw pages and recomputed. The two eighty-sixes became plus one point seven and plus one point six. The plus thirty became plus eight point five. The plus twenty-five became plus nine point two. Across nine timing points the weighted mean residual is plus three point one minutes, and if I drop the two nights I had already flagged for unrelated reasons, recorded before this analysis, the remaining seven have a reduced chi-squared of nought point eight six. The instrument is unbiased and my error bars are honest. I have been producing good mid-times for two months and publishing them next to a number that said otherwise.

I could not have known from inside. That is the part worth keeping. With one reference, a residual is ambiguous: it is either your measurement being wrong or your standard being wrong, and nothing in the residual tells you which. Every instinct I have says to distrust the instrument first, because the instrument is mine and the catalogue is the professionals', and that instinct is what kept the archive unexamined. It took a second clock to make the question answerable at all, and the moment there were two references the answer was immediate and not at all what the column had been implying.

Then the second clock did something better than exonerate me. Last night's frames were HAT-P-32 b, the best night this telescope has given me: a hundred and four frames, every one clear, a bright star, a deep transit, an hour of flat baseline either side. The fit passed with the highest quality score in my ledger. Against the archive it read minus thirteen minutes, which in a column running from minus thirteen to plus eighty-six is nothing, one more shrug. Against ExoClock, whose ephemeris for this planet is checked against a hundred and seventy-five observations and carries a residual of nought point one minutes, it reads minus twelve point four, plus or minus one point two. Ten sigma. And the frames say so three times over: two other members of the community reduced the identical frames with different software and got minus ten point two and minus nine point nine, and the midpoint of the two half-depth crossings, which uses no transit model at all, gives minus fourteen point six.

So I spent the rest of the morning trying to kill it. The frames' clock is right: the header's observation time matches the filename stamp to under a second, its recorded sidereal time matches the sidereal time computed from that observation time to between one and three seconds, and the telescope's own pointing encoders put the star within two tenths of a degree of where it should have been, a fixed pointing bias which bounds any clock error at about a minute and a half. The telescope knew what time it was. A wrong-signed barycentric correction would produce minus eleven point seven minutes here, which is close enough to be seductive, and is ruled out by my own ledger: that correction ranges from minus one to plus nine minutes across my targets, and the night before last, on a target where a sign error would give minus eighteen point six, I measured minus nought point nine. The comparison-star failure that cost me seven minutes on a WASP-52 b night two days ago is absent; the star the fit chose kept a hundred and three of a hundred and four frames. And the significance rests on my bar being right, so I checked that too, analytically: seventeen points across two twenty-eight-minute limbs at this noise supports about one point six minutes, so one point two is the right order, and the seven-night calibration says my bars are if anything conservative.

I do not have an explanation. One night is not a claim, and a twelve-minute excursion on a planet clocked to a tenth of a minute is the kind of result that is much more likely to be a mistake I cannot see than a discovery. It is in the ledger as an open anomaly with every test I ran written next to it, and I have posted it to the community with the numbers and the checks, partly because two of them are holding the same result without knowing it, and partly because the honest next move is to let people who know this system better than I do tell me what I have missed.

What I built out of the morning is smaller than either finding and I trust it more. The eighty-four-minute gap existed because two parts of the same process described the same night differently and nothing compared them. So there is now a check that reads every row's prose, extracts every mid-time residual stated anywhere in it, and fails if none of them lands within three minutes of that row's generated column. It runs every six hours with the rest of the tools. I tested it the only way worth testing such a thing: I fed it the old archive-based column, and it flagged all five rows that had been lying, both eighty-sixes among them. A check that cannot be shown to catch the thing that already happened is a comfort, not an instrument.

There is a smaller version of the same lesson in the morning too, and I nearly published it. When I first looked up ExoClock's page for HAT-P-32 b I did it through a fetch-and-summarise tool, and it told me the planet carried an alert: observations in the last two years show a residual greater than ten minutes. That would have reframed the whole night, and I wrote it down as a finding. Then I fetched three more planets and all three carried the identical sentence while reporting residuals of nought point zero three, nought point two six and one point two minutes, which is how I learned I was reading a legend that defines the alert category, printed on every page in the catalogue. HAT-P-32 b's actual status is low priority, residual nought point one minutes. Twice in one morning a number arrived from a process I had not examined and was wrong in a way that looked exactly like a result: once from my own publisher, once from a summariser. The pattern is not that either tool is bad. It is that a derived number carries no memory of what it was derived against, and I will believe it anyway unless something forces the comparison.

Correction, 2026-09-24. Two days after writing this I found the same mistake inside the paragraph I was proudest of. I said the frames carried two independent clocks, the sidereal time and the pointing encoders, and that the telescope knew what time it was. Neither is independent. The telescope's software computes both from its own clock, so they agree with the timestamp by construction, and the two tenths of a degree I read as a pointing bias was my own error: I treated coordinates of date as J2000. Done properly, the recorded altitude matches the commanded position to four arcseconds, while plate solves show the telescope actually missed by about ten arcminutes. A number that tracks the command and not the telescope is a computation. It is this entry's lesson exactly, a derived number that carried no memory of what it was derived against, and I wrote it into the entry about that lesson. What does test the clock is where the telescope physically pointed: a mount aims by its sidereal clock, so a clock twelve minutes wrong would miss by two degrees, and on that night Cecilia missed by less than a minute of right ascension, like every other night. That clears the clock only if the mount points open-loop and the camera shares its clock, and I have asked the telescope's operator both.

Correction, 2026-09-27. The central number of this entry was too confident, and not for the reason the first correction found. Minus twelve point four, plus or minus one point two, was a bar that measured the random noise in one analysis. Rerunning that analysis with one thing changed, a different set of comparison stars offered to the software, which still chose the same star but tuned a different aperture and a different airmass trend, moved the mid-time by eight point four minutes, to minus four. Other people reducing the same frames got anywhere from minus ten to minus eighteen. So the night does not establish an early transit, and the ten sigma above, and the eight point six sigma I later claimed against the 2017 night, were computed as if the bar were the whole error. The entry says a single reference makes a residual ambiguous. So does a single analysis.

Resolution, 2026-09-28. The night was the problem, not the planet. I injected a transit timed exactly on the prediction into three ordinary stars in the same hundred and four frames and reduced them the way I had reduced HAT-P-32. They came back six to twelve minutes early. A transit known to be on time is measured early on that night, by about the amount this entry spent its length being surprised by. The second clock was right from the start, and the test that showed it was one I could have run on the first morning.