旧暦表示エラーの説明とOTAアップグレード案内
—— 労働節おめでとうございます！—
皆様、4月27日以降に時計の旧暦日付がずれていることに気づきませんでしたか？これはソフトウェアのバグであり、すでに修正済みです。
経緯
4月28日、ユーザーから「旧暦表示が実際より1日多い」との報告を受けました。当初は半信半疑でしたが、検証の結果、確かに旧暦計算のミスと判明。その日のうちに原因を特定し、修正版をリリースしました。
影響を受ける機種
弊社で旧暦表示機能のある時計はすべて影響します。現象：旧暦日付が1日進みで表示されます。たとえば4月27日は本来「三月三十」ですが、「四月初一」と表示されます。
対処方法
- 影響期間：2025年4月27日～2025年5月26日（5月27日以降は自動的に正常に戻ります）。気にならない場合は、そのままお待ちいただいても構いません。
- 1.9.xバージョン（WHEN時計）へアップグレード。旧暦表示を利用される方は、記事末尾の方法でご連絡ください。
この問題は広く存在します
このバグは、万年暦・時計・出勤管理機などあらゆる機器で発生しています。
旧暦機能のある機器をお持ちの方はご確認ください。ネット検索でも多くのスマートフォンで同様の現象が確認できます。
技術的原因と旧暦アルゴリズムの経緯
このパートは技術寄り・組み込み開発に興味のある方向けです。
現象：
2025年4月27日～2025年5月26日、旧暦が実際より1日進みで表示。
直接原因：
「3バイト年コード」旧暦アルゴリズムの1ビットミス。
3バイト年コードの由来：
旧暦計算は単純なオフセットでなく複雑な計算を要します。初期MCUリソースの制限から、1901～2099年の旧暦をROMに直接テーブル化して格納する方式（3バイト年コード）が考案されました。これにより複雑な計算や大きなメモリ確保を避けられます。
主な年代と資料：
| 年代 | 資料・人物 | マイルストーン |
|---|---|---|
| 1994 | 『コンピュータプログラミング技術とメンテナンス』誌 | Turbo Cによる4バイト×199年の旧暦テーブルを発表 |
| 2002 | 8052.com / 電子工学フォーラム | Campo氏が「3バイト年コード＋Cルーチン」（600バイト）を公開 |
| 2004-2007 | 各種MCUベンダー | 電子万年暦・時計音声チップDEMOに組み込み、派生多数 |
| 2010年以降 | Arduino/ESP8266中国コミュニティ | 再び流行し、GitHubに10以上のフォークが登場 |
以降、「3バイト×199年」が旧暦計算の業界標準となりました。
リスク要因：
- 手入力ミス：1ビットの誤りでその月全体が+1/-1日ずれる
- 遅延露呈：多くは10～20年後に発覚（例：2025、2033、2093）
- 分岐と追跡困難：フォーラムで様々な修正が混在し、どのテーブルが正しいか下流では分かりづらい
こうしたテーブルは広く流用され、再チェックされることはほとんどありません。
残念ながら、その中にバグが混入していたのです！
影響する主な年と現象
| 年 | 想定される不具合 |
|---|---|
| 2033 | 閏月コードのミス→「2033バグ」8ヶ月のずれ |
| 2025 | 三月/四月の日数逆転→三月三十が四月初一に表示 |
| 2036 | 閏月情報誤り→6月以降すべて旧暦1ヶ月ずれ |
| 2091 | 旧正月日付+1→2月1日と表示される |
| 2093 | 閏月エラー→冬の月全体がずれる |
近年こうした不具合が顕在化しています。OTA対応機種なら修正可能ですが、古い機器はメンテナンスやアップグレードが難しく対応できません。幸い、影響するのは1ヶ月程度で重大な障害とはなりません。
なぜこの“小さなバグ”にこだわるのか
この年コードテーブルは私のプロジェクトにも使っており、ついに自社製品で発覚。根本原因を突き止めなければ完全な修正ができません。
小さなバグですが、十年以上潜伏し続ける厄介なものです。このエラーが広く知られなければ、今後も修正されないコードが多くの機器に残り続けます。
これは特定メーカー固有の事故ではなく、「コピペ文化」の縮図とも言えます。
改めて実感しました——「世界は仮設劇団でできている」
小規模チームの“借用主義”は仕方ありません。しかし大企業であっても「動けばOK」と検証せず古いコードをコピー・統合・量産してしまう現実があります。
私が以前の職場で聞いた言葉を思い出しました：
「技術には畏敬を持ち、製品開発は薄氷を踏む思いで」
自社製品のOTAアップグレード方法
