パッチ 2026年4月

Patched 2026/03

2026年4月に実施した、本アプリの追加機能、問題点の修正をまとめます。

• 機能追加 なし
• 修正
  1. ブログ保存完了時のデザインの修正
  2. タイムゾーンの混合バグ

機能追加

->「なし」 ここに書くのが適切なのか分かりませんが、来月再来月にマークダウンの大幅回収をしようと思います。
今のこのブログの記述面に多くの不満点を感じることが原因です。
その方針について改めて決まったら書こうと思います。

修正

1. ブログ保存完了時のデザインの修正

セキュリティの観点から詳しいことは書けませんが、ブログ保存完了の際特定の表示をさせるのですが、それが場合によっては大きく崩れていた為訂正しました。
正直小さなcss(tailwindcss)の問題です。

2. タイムゾーンの混合バグ

こちらは少し大きなバグだったので詳しく説明します。

・問題の概要

「記事の公開・更新の際に指定する日時指定について、なぜか更新の際には指定した日時から9時間進んで保存される」

例えば、「2026-04-30 10:00」を指定して保存したつもりが、更新した際に再び公開日時を確認すると「2026-04-30 19:00」になっていました。
きっちり9時間ずれていたので、おそらくタイムゾーンのズレの問題だと思いながら修正を進めました。

・原因

「タイムゾーンへの配慮がないまま時間指定の処理を書いていた。」

保存時に、フォームからくる値はおそらくこのような形だったのでしょう。

2026-04-28T10:55 

それを保存時にバックエンドでは、

//　例
detavalue = '2026-04-28T10:55';

const deta = new Date(detavalue);

この時、「deta」を使ってDBに保存する、とこれがJSTなのかUSTなのかわかりません。

これが公開日を表示するだけなら、実害がなかったのですが(実害がなかっただけで問題なのは変わりないが)
問題は、「記事を編集」する時です。

記事を編集するときは、もちろん一度dbに保存したデータを持ってきます。
実際ここで確認した時に、最初に指定していた公開日時より9時間進んでいることに気がつきました。

つまりこういう事だと推測できます。

入力時：2026-04-28T10:55 (UTSで言うと2026-04-28 1:55)

保存時：'2026-04-28T10:55'　-> deta型に'2026-04-28T10:55:00.000Z'　タイムゾーンが分からずUTSで保存される

取得時：date = row.publishedAt.toString(); <-この「toString()」もマズイ。「toISString()」で取得するようにする。

表示時：<input type="datetime-local"　-> dateの値をdatetime-local に戻すとJSTローカルとして9時間進められて 「19:55」になる

input datetime-localはユーザーのローカルタイムゾーンにおける時刻」を文字列として扱います。
これがずれの原因でした。

・対策

「日時はUTSで管理されると言う前提で処理し、表示時(特にdatetime-local に戻すとき)は'toISOString()'でタイムゾーン込みの情報を正しく渡す」

以上、Patched 2026/04　でした