和暦西暦誤認バグ

西暦和暦誤認バグ

[413] 和暦の実装の中には、 最初の元号である大化より前の時代をすべて大化として扱い、 建元前は0年や負の年 (-1年、-2年、...) とするものもあります。 あまり一般的な紀年法ではありませんし、 意図せず、または実装の便宜上採られた方法と思われます。 適切な年の表現方法とは思われませんから、 これに倣うべきではありません。 元号一覧大化日本古代の日時, CLDRの和暦

[880] iOS には和暦使うよう設定していると、 元号年の年数部分が西暦年と解釈され、 それが元号として表示されて大化のマイナス六百何十年となる (例えば平成27年 → 西暦27年 → 大化-617年となる) 問題があるようです。 >>879, >>877, >>878 複数の写真アプリで報告されていますが、 プラットフォーム側の問題なのか、 特定アプリの実装上の (ありがちな) 問題なのか不明です。 生成された画像Exif データに本来元号年たる誤った西暦年が書き込まれるらしく、 発症していると報告されたアプリに原因があるとも限りません。 写真アプリ以外への影響も不明です。 なお、 この問題に言及する WebページSNS の投稿には、「-」を見落としているものも複数ありました。

[883] それにしてもこの被害報告はあちこちでみられ、 iPhone和暦設定で使っている人は案外多いようです。
[15] Android西暦にしか対応しないという邪悪な手法でこのような問題を回避しています。 Googleによる多様性の軽視

[14] iOS アプリの開発者は、 OS の設定を和暦にして正常に動作することを必ず確認するべきです。 複数人で開発しているなら、日頃から開発メンバーの何人かは西暦、 何人かは和暦に設定しておくのがいいでしょう。 和暦で異常動作する箇所や。 設定に応じて和暦になるべきなのに西暦のままになってしまう箇所の洗い出しに便利です。

[882] その他、 大化元年より前の日付を適切に扱えない実装もみられるようです >>881。 0年や負の年の扱いに問題があるか、 最初の紀年法たる大化より前に紀年法が用意されておらず問題が起こっているのでしょうか。


[1] 逆パターンで、 西暦年を最新の元号たる令和 (または平成) と誤認することによる障害も報告されています >>3, >>2, >>4

[4] ‎くら寿司 公式アプリ Produced by EPARK on the App Store () https://apps.apple.com/jp/app/%E3%81%8F%E3%82%89%E5%AF%BF%E5%8F%B8-%E5%85%AC%E5%BC%8F%E3%82%A2%E3%83%97%E3%83%AA-produced-by-epark/id942355925?l=en

3.0.10Feb 3, 2020

ver 3.0.10

・端末設定による不具合の修正

暦法設定を「和暦」に設定している場合、4038年(OSによっては4008年)として予約を受け付けてしまう不具合を修正しました

[10] Android でこの種の報告がないので、 iOSApple 製品の品質が低いのかと誤解しそうですが、 Android和暦に対応していないため問題が顕在化していないと思われます。 Android が対応したら同様の問題が多発する、 あるいはそれが懸念されるから対応できないのかもしれません。

[11] なんにせよ和暦に対応しない Google の日本市場の軽視が透けて見えるようです。 この点では Apple の対応がずっと進んでいます。 (世界的に見ても日本iOS シェアは高いといわれていますから、 両者の姿勢がこうなるのも当然かもしれません。)

[12] どちらかといえば、 全世界対応の iOS で日本市場向けの地域化にしっかり取り組もうとしている Apple にあまり非はなく、 日本市場向けの日本企業の製品であるにも関わらず和暦対応の動作確認すら怠っている日本の一部アプリ開発者の技術レベルの低さによってもたらされた障害のような感があります。

[6] 現代日本の紀年法

[588] はてなブックマーク - 「喜多方ラーメン」誤表示、原因は12年前の… JR東:朝日新聞デジタル ( ()) https://b.hatena.ne.jp/entry/www.asahi.com/articles/ASJ6N3GRCJ6NUGTB002.html

某所にて、2016年と平成16年(2004年)のデータ出力ミスとの説を見かけた。

[7] Google、令和2年を西暦2002年と誤認する | LARTHの日記 | スラド, 2020年02月22日 2時52分, https://srad.jp/~LARTH/journal/636976/

[8] >>7PDF のみ言及していますが、 HTML でも誤認されているようです。 Google検索が「令和」の元号に対応しておらず (「平成」に対応しているかは不明)、 「2年」を2桁西暦年と解釈して 「2002/02/17」 のように表示しているようです。

[463] 【iPhone】iOSのバグ対策、iPhoneの写真が「大化」年号表示になる時の対処方法。 | Cohtaro.com ( 版) http://cohtaro.com/2015/01/3690

最近メインで使っているカメラアプリ「Cortex Cam」で撮影した写真の日付けがごっそり「大化」(大化改新などの年号)になってしまうので困っていました。

対処方法をネットで調べてみたのですがでてきません。

根本的な原因がiOSのバグらしいこと。「平成27年」が0027年に変換されて、大化617年に再計算されるということで打つ手なし。かと思ったのですが、設定をいじってみたら問題解決できました。

[9] とある Webサイト日付入力欄 (おそらく何か欧米製のJavaScriptフレームワークウィジェットそのまま利用) は、 自由入力 + プルダウンのカレンダーからの選択の2通りの入力が可能なものでした。 自由テキスト入力の方に「R3/1/2」と書いてみたら、 「0003/01/02」 に正規化されたようでした。

このシステムがこの入力をどう処理したのか画面からはわかりませんでしたが、 西暦3年と誤認されてそうで怖いですね。

きっと欧米人か経験の浅い日本人が作ったもので (偏見)、ここに数字以外が入力されるはずがない、 西暦以外が入力されるはずがない、 と勝手に思い込んでこういう作りにしちゃったんでしょう。

[13] 欧米人が作ったならまあ仕方ないかなあという気がしますが、 日本人技術者が仕様を決めて日本人開発者が作って日本企業が検収してるのだとしたら、 もっと仕事をしっかりしろよ、と。