何が起きているのか
ラップトップをスリープから復帰させ、WSL2を開いて apt-get update を実行すると、次のエラーが表示されます：
E: Release file for http://archive.ubuntu.com/ubuntu/dists/jammy-updates/InRelease is not valid yet (invalid for another 7h 23m 12s). Updates for this repository will not be applied.
あるいは git pull でSSL証明書エラー — "certificate is not yet valid" が発生することもあります。根本原因は同じです：WSL2の時刻が過去の時刻で止まっています。
内部で何が起きているかというと、Windowsがスリープまたは休止状態になると、WSL2のVMも完全に一時停止します。復帰時、Linuxカーネルはどれだけの時間が経過したか把握できず、停止した時点からそのまま再開します。7時間スリープすれば、WSL2の時刻は7時間遅れます。タイムスタンプを確認するツールはすべて壊れます——apt-get、HTTPS経由のgit、curl、TLSハンドシェイク——すべてが影響を受けます。
即時修正（コマンド1つ）
WindowsのハードウェアクロックをWSL2のシステムクロックにコピーします：
sudo hwclock --hctosys
実行前後に date を実行して時刻の変化を確認します：
date
# Thu Jun 18 03:21:45 UTC 2026 ← 数時間遅れている
sudo hwclock --hctosys
date
# Thu Jun 18 10:47:02 UTC 2026 ← 正しい時刻
その後 apt-get update を再試行してください。"not valid yet" エラーは解消されているはずです。
hwclock がない場合は、代わりに ntpdate を使用します：
sudo apt-get install -y ntpdate
sudo ntpdate time.windows.com
最終手段：PowerShellからWSL2を再起動する方法もあります。Windowsは起動時にVMの時刻をリセットするため、これは確実に機能します。実行前に開いている作業を保存してください。
# すべてのWSLセッションを閉じる
wsl --shutdown
WSL2ターミナルを再度開くと、時刻が正しくなっています。
修正を確認する
# 時刻を確認
date
# 失敗したコマンドを再実行
sudo apt-get update
# gitの場合
git pull
apt-get の出力に "not valid yet" が表示されなければ成功です。gitの場合、クリーンなpullまたはfetchが成功すれば、SSLも正常に機能しています。
恒久的な修正 — 再発を防ぐ
ラップトップが復帰するたびに sudo hwclock --hctosys を入力するのはすぐに面倒になります。Ubuntuのバージョンに応じて、以下のいずれかを選択してください。
オプション1：systemdを有効化する（Ubuntu 22.04以降 — 推奨）
Ubuntu 22.04以降はWSL2内でsystemdをサポートしています。有効化すると、systemd-timesyncd がNTP同期を自動的に処理するため、時刻について意識する必要がなくなります。
/etc/wsl.conf に以下を追加します：
sudo tee -a /etc/wsl.conf <<EOF
[boot]
systemd=true
EOF
PowerShellから再起動します：
wsl --shutdown
WSL2を再度開き、同期サービスが動作していることを確認します：
systemctl status systemd-timesyncd
active (running) と表示されれば完了です — 以降、時刻のずれは自動的に処理されます。
オプション2：シェル起動時に自動同期する（Ubuntu 20.04 / systemdなし）
ターミナルを開くたびに実行されるよう、シェルの起動ファイルにサイレントな hwclock 呼び出しを追加します：
# ~/.bashrc または ~/.zshrc に追加
if [ -n "$WSL_DISTRO_NAME" ]; then
sudo hwclock --hctosys 2>/dev/null || true
fi
パスワード入力を省略するには、hwclock のみにパスワードなしのsudoを許可します：
sudo visudo
末尾に以下の行を追加します（yourusername を実際のLinuxユーザー名に置き換えてください）：
yourusername ALL=(ALL) NOPASSWD: /sbin/hwclock
以降、新しいターミナルを開くたびに、最初のコマンドを入力する前にサイレントで時刻が同期されます。
オプション3：精度のためにchronyをインストールする（TLSデバッグ、Kerberos、分散システム）
証明書のデバッグ、Kerberos認証、分散ノード間での協調処理など、ミリ秒単位の精度が必要な作業では、chrony は一度きりの hwclock より安定しています：
sudo apt-get install -y chrony
sudo systemctl enable chrony
sudo systemctl start chrony
正しく追跡されているか確認します：
chronyc tracking
正常な出力では Leap status: Normal が表示され、System time のオフセットがミリ秒の範囲に収まっています。ミリ秒ではなく秒単位のオフセットが表示される場合は、同期がまだ収束中です——30秒待ってから再確認してください。
なぜWSL2だけでWSL1では発生しないのか
WSL1はLinuxのシステムコールをWindowsカーネル上で直接実行していました。常にWindowsのシステムクロックを使用していたため、時刻のずれは発生しませんでした。
WSL2は仕組みが異なります。軽量なHyper-V VM内で本物のLinuxカーネルを実行しています。マシンをスリープさせると、そのVMは完全に一時停止します。復帰時、WindowsはVMに経過時間を伝えないため、Linuxの時刻が単純にずれてしまいます。
これはWSL2の既知の制限事項です。上述の hwclock とNTPの対処法が確立されたワークアラウンドです。WSLチームは復帰時の自動時刻補正に取り組んでいますが、それがリリースされるまでは、手動同期またはsystemdが信頼性の高い方法です。