[413]
和暦の実装の中には、
最初の元号である大化より前の時代をすべて大化として扱い、
建元前は0年や負の年 (-1年、-2年、...) とするものもあります。
あまり一般的な紀年法ではありませんし、
意図せず、または実装の便宜上採られた方法と思われます。
適切な年の表現方法とは思われませんから、
これに倣うべきではありません。
元号一覧、大化、日本古代の日時, CLDRの和暦
[880]
iOS
には和暦を使うよう設定していると、
元号年の年数部分が西暦年と解釈され、
それが元号として表示されて大化のマイナス六百何十年となる
(例えば平成27年 → 西暦27年 → 大化-617年となる)
問題があるようです。
>>879, >>877, >>878
複数の写真系アプリで報告されていますが、
プラットフォーム側の問題なのか、
特定アプリの実装上の (ありがちな) 問題なのか不明です。
生成された画像の Exif
データに本来元号年たる誤った西暦年が書き込まれるらしく、
発症していると報告されたアプリに原因があるとも限りません。
写真系アプリ以外への影響も不明です。
なお、
この問題に言及する
Webページや
SNS
の投稿には、「-」を見落としているものも複数ありました。
[14]
iOS アプリの開発者は、 OS の設定を和暦にして正常に動作することを必ず確認するべきです。
複数人で開発しているなら、日頃から開発メンバーの何人かは西暦、
何人かは和暦に設定しておくのがいいでしょう。
和暦で異常動作する箇所や。
設定に応じて和暦になるべきなのに西暦のままになってしまう箇所の洗い出しに便利です。
[882]
その他、
大化元年より前の日付を適切に扱えない実装もみられるようです >>881。
0年や負の年の扱いに問題があるか、
最初の紀年法たる大化より前に紀年法が用意されておらず問題が起こっているのでしょうか。
[1]
逆パターンで、
西暦年を最新の元号たる令和 (または平成)
と誤認することによる障害も報告されています
>>3, >>2, >>4。
- [5] iPhoneのカレンダー設定を和暦にしていると、日付と曜日がずれる問題が起こる - odawaraの「はてな de メモ」,
2011-06-13,
https://odawara.hatenadiary.org/entry/20110613/1307946819
- [879] tako@お財布0円さんはTwitterを使っています: 「iOS7にアップデートしたらカメラロールを撮影年別表示できるようになったんだけど、一枚だけ千年以上前に撮影されてた。 http://t.co/6yAP8GIWYp」 / Twitter,
午前10:33 · 2013年9月21日,
https://twitter.com/kutarcom/status/381229620663554050
- [877] 【iPhone】iOSのバグ対策、iPhoneの写真が「大化」年号表示になる時の対処方法。 | Cohtaro.com,
2015年1月13日,
http://cohtaro.com/2015/01/3690
- [881] 平成最後の年頭にあたりmacOSの改元対応を考える - 新・OS X ハッキング!(231) | マイナビニュース,
海上忍,
2019/01/16 08:00,
https://news.mynavi.jp/article/osxhack-231/
- [878] iPhone写真の日付問題は|これで解決|【厳選5技】,
2019年10月21日,
https://happiness-repair.com/media/know-how/893/
- [3] 来店予約がなぜか「4038年」に、くら寿司アプリで和暦対応の不具合か | 日経 xTECH(クロステック), 日経 xTECH(クロステック),
2020/02/03 20:10,
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/07007/
- [2] くら寿司の予約アプリで4038年になった理由 - Windows 2000 Blog,
2020年02月04日,
http://blog.livedoor.jp/blackwingcat/archives/1993655.html
[10]
Android
でこの種の報告がないので、
iOS や Apple
製品の品質が低いのかと誤解しそうですが、
Android
が和暦に対応していないため問題が顕在化していないと思われます。
Android
が対応したら同様の問題が多発する、
あるいはそれが懸念されるから対応できないのかもしれません。
[11]
なんにせよ和暦に対応しない Google の日本市場の軽視が透けて見えるようです。
この点では Apple の対応がずっと進んでいます。
(世界的に見ても日本の iOS シェアは高いといわれていますから、
両者の姿勢がこうなるのも当然かもしれません。)
[6] 現代日本の紀年法
[7] Google、令和2年を西暦2002年と誤認する | LARTHの日記 | スラド,
2020年02月22日 2時52分,
https://srad.jp/~LARTH/journal/636976/
[8] >>7 は PDF のみ言及していますが、 HTML でも誤認されているようです。
Google検索が「令和」の元号に対応しておらず
(「平成」に対応しているかは不明)、
「2年」を2桁西暦年と解釈して
「2002/02/17」
のように表示しているようです。
[9]
とある Webサイトの日付入力欄 (おそらく何か欧米製のJavaScriptフレームワークのウィジェットそのまま利用)
は、
自由入力 + プルダウンのカレンダーからの選択の2通りの入力が可能なものでした。
自由テキスト入力の方に「R3/1/2」と書いてみたら、
「0003/01/02」
に正規化されたようでした。
このシステムがこの入力をどう処理したのか画面からはわかりませんでしたが、
西暦3年と誤認されてそうで怖いですね。
きっと欧米人か経験の浅い日本人が作ったもので (偏見)、ここに数字以外が入力されるはずがない、
西暦以外が入力されるはずがない、
と勝手に思い込んでこういう作りにしちゃったんでしょう。
[13]
欧米人が作ったならまあ仕方ないかなあという気がしますが、
日本人技術者が仕様を決めて日本人開発者が作って日本企業が検収してるのだとしたら、
もっと仕事をしっかりしろよ、と。