Wixで10月1日が描画後に9月30日へ変わった――保存日時を変えず表示側を日本時間へ直した記録

読込直後は10月1日、その後9月30日へ変わると報告された

2026年10月1日、「海辺の部屋」のKnowledge公開表示で日付が意図した日付とずれる問題が確認されました。

当時のdotは、ページを読み込んだ直後には10月1日と表示され、その後の画面描画で9月30日へ変わる挙動を再現したと報告しています。

この記録では、最初から保存データが9月30日だったとは扱っていません。表示の途中で見え方が変わったことを、保存値とは別の現象として扱いました。

保存日時まで直してしまう前に、元データを残した

日付が1日ずれて見えると、CMSの日時そのものを1日進めて保存し直す方法も考えられます。

しかし、もし元データが正しく、表示時の変換だけがずれているなら、保存値まで変更すると別の環境ではさらにずれる可能性があります。

そのため当時の修正では「元の日時データは変更していない」と明示し、保存値と画面表示を分けて扱いました。

dotは閲覧側の時間帯が表示へ関係すると診断した

dotは、画面描画後の表示が閲覧者の時間帯に合わせて変換されていることが関係すると診断し、Knowledgeの日付表示を日本時間へ統一する方向へ変更したと報告しています。

ただし、本記事制作時に当時のWixコードやブラウザーのタイムゾーン処理を再検証して、技術的な根本原因を独立に確定したわけではありません。

ここで確実に残せるのは、読込直後と描画後で表示日が変わったというdotの再現報告と、表示側を変更したという作業記録です。

修正対象を「保存日時」ではなく「表示側」にした

修正では、CMSに保存された日時をずらすのではなく、Knowledgeページ側の日付表示を日本時間へ統一する方法が選ばれました。

これによって、データの基準時刻を変更せず、閲覧時にどう日付として見せるかだけを調整できます。

日付の表示問題を直すときも、データ層と表示層を同じ変更対象にしないという考え方です。

プレビューだけで終わらず、公開2記事でずれが消えたと報告された

dotは表示方式を変更した後、プレビューで確認し、さらに公開済みの2記事で日付ずれが解消したと報告しました。

この2記事での確認は、少なくともその修正後の表示が意図した日付になったという当時の完了報告です。

すべての記事、すべての端末、すべてのタイムゾーンで同じ結果になることまで検証した記録ではありません。

同じ「日付」でも、確認する場所を分ける

この一次体験からは、日付問題を一つの値として扱わず、少なくとも次の状態を分けて確認できます。

保存日時：CMSへ実際に保存されている日時。

読込直後の表示：ページが最初に返した時点で見えている日付。

描画後の表示：ブラウザー側の処理後に実際に見える日付。

表示基準：UTC、日本時間、閲覧者時間帯など、日付へ変換するときの基準。

どこで値が変わったかを確認してから、変更対象を決めます。

保存値が正しいなら、表示異常だけで元データを壊さない

この事例で重要なのは、日本時間へ変換すればすべてのWix日付問題が解決するという一般則ではありません。

表示が誤って見えたとき、元データまで誤っていると決めず、保存値と表示処理を別に確認したことです。

前の記事で扱った紹介文・ALT・urlKeyの接続ミスと同様、CMSに正しい値が存在していても、表示側の処理や接続で見え方が変わることがあります。

このKnowledgeで言える範囲

本記事が記録しているのは、2026年10月1日にdotが「読込直後10月1日→描画後9月30日」という表示変化を再現し、保存日時は変更せず、表示側を日本時間へ統一した後、公開2記事でずれが消えたと報告した具体例です。

Wixの一般仕様として必ず同じ変換が起こること、閲覧者時間帯が根本原因だったこと、すべての端末で同じ修正が有効だったことは、本記事では確認していません。

このKnowledgeの関連知識

表示層の別の実例：Wix CMSで紹介文に画像ALT、画像ALTにURLキーが出た――保存内容と表示先を分けて直した記録。保存値と画面要素の接続先を分けた事例です。

時点を分ける考え方：Blog件数が243→252→256と変わった――公開・更新・測定・主張の4つの時点を分けて残す。日時や数値をどの時点の記録として扱うかを整理します。

外部操作の確認：AIに外部サービスを操作させるとき「送信した・保存された・表示された」を分けて確認する。保存結果と実際の表示を別段階で確認します。