Linux、新元号に対応できず、バグ発生で阿鼻叫喚
日本語入力の漢字変換だけ対応したら、オッケーじゃまいか YouTubeで文字だけスクロールする動画のタイトルみたいなスレタイだな 会計とか実務関係は西暦にすれば済む話なんだが、実は買い換え利権が絡んでるから、解決しない >>47-48
Kondaraとか懐かしいな。
各版のコードネームがLinux Mintみたいに女性名だったことを覚えてますね。 新元号「令和」と文字コード(主にUnicode)の問題
https://togetter.com/li/1333809
U+4EE4 U+F9A8 、共に割り振られている文字が、"令"
(Linux板では数値文字参照が使えないので U+F9A8 がどう表示されるかを、
ここでお見せ出来ないのが残念ですw) I18N: 令の字にUNICODEのコードが2つあったはなし 2019-04-01
https://opcdiary.net/?p=52401
めでたく、新元号が「令和」となったわけですが、令に「令(U+4EE4)」と「令(U+F9A8)」が
有る事がわかりました。とは言っても、基本的に後者の方はCJK互換漢字に分類され、
U+F900 – U+FA0Bは韓国の文字コード企画KS X 1001との往復変換を可能にするために追加
された文字(一部文字はJIS X 0123と共有しているがこの字は異なる)なので、「令和」の場合、
後者を使用することは無さそうと言うか、UNICODEへの収録意図から使うべきでは無いでしょう。
という事で、UNICODE正規化で文字が変わるという事もなく、これで安心。
さて、Windowsの標準フォントや、IPAフォントのへの合字の方のフォント収録はいつ頃に
なるんでしょうね :P >>54
新年号には対応していないな
$ date +'%EY' --date="next year"
平成32年 Windows 10・WSL・Ubuntu 16.04 だけど、
/usr/share/i18n/locales/ja_JP のera の部分に、新元号の令和が追加されるのかな? Windows 10・WSL・Ubuntu 16.04 だけど、
/usr/share/i18n/locales/ja_JP のera の部分、
era "<U002B><U003A> 〜続く。
この部分を、Ruby で変換したもの
era "+:2:1990/01/01:+*:平成:%EC%Ey年";/
"+:1:1989/01/08:1989/12/31:平成:%EC元年";/
"+:2:1927/01/01:1989/01/07:昭和:%EC%Ey年";/
"+:1:1926/12/25:1926/12/31:昭和:%EC元年";/
"+:2:1913/01/01:1926/12/24:大正:%EC%Ey年";/
"+:2:1912/07/30:1912/12/31:大正:%EC元年";/
"+:6:1873/01/01:1912/07/29:明治:%EC%Ey年";/
"+:1:0001/01/01:1872/12/31:西暦:%EC%Ey年";/
"+:1:-0001/12/31:-*:紀元前:%EC%Ey年"
era_d_fmt "%EY%m月%d日"
era_d_t_fmt "%EY%m月%d日 %H時%M分%S秒" 現在のこれを、
era "+:2:1990/01/01:+*:平成:%EC%Ey年";/
"+:1:1989/01/08:1989/12/31:平成:%EC元年";/
以下に修正すればよい
era "+:2:2020/01/01:+*:令和:%EC%Ey年";/
"+:1:2019/05/01:2019/12/31:令和:%EC元年";/
"+:2:1990/01/01:2019/04/30:平成:%EC%Ey年";/
"+:1:1989/01/08:1989/12/31:平成:%EC元年";/ 現在のこれを、
era "+:2:1990/01/01:+*:平成:%EC%Ey年";/
以下に修正すればよい
era "+:2:2020/01/01:+*:令和:%EC%Ey年";/
"+:1:2019/05/01:2019/12/31:令和:%EC元年";/
"+:2:1990/01/01:2019/04/30:平成:%EC%Ey年";/
次へ続く 行が長すぎて書き込めないので、途中で改行しています。
バイトサイズの制限だけにしておけばよいのに、迷惑な制限!
変更前
era "<U002B><U003A><U0032><U003A><U0031><U0039><U0039><U0030><U002F><U0030>
<U0031><U002F><U0030><U0031><U003A><U002B><U002A><U003A><U5E73><U6210>
<U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
変更後
era "<U002B><U003A><U0032><U003A><U0032><U0030><U0032><U0030><U002F><U0030>
<U0031><U002F><U0030><U0031><U003A><U002B><U002A><U003A><U4EE4><U548C>
<U003A><U0025><U0045><U0043><U0025><U0045><U0079><U5E74>";/
"<U002B><U003A><U0031><U003A><U0032><U0030><U0031><U0039><U002F><U0030>
<U0035><U002F><U0030><U0031><U003A><U0032><U0030><U0031><U0039><U002F>
<U0031><U0032><U002F><U0033><U0031><U003A><U4EE4><U548C><U003A><U0025>
<U0045><U0043><U5143><U5E74>";/
"<U002B><U003A><U0032><U003A><U0031><U0039><U0039><U0030><U002F><U0030>
<U0031><U002F><U0030><U0031><U003A><U0032><U0030><U0031><U0039><U002F>
<U0030><U0034><U002F><U0033><U0030><U003A><U5E73><U6210><U003A><U0025>
<U0045><U0043><U0025><U0045><U0079><U5E74>";/ >>58
に書いてある、大正元年の+:2 は、+:1 の間違いじゃないの?
"+:2:1913/01/01:1926/12/24:大正:%EC%Ey年";/
"+:2:1912/07/30:1912/12/31:大正:%EC元年";/
まあ、でも正常に動くけど
date +'%EY' --date="1912/07/30"
大正元年 日本の公文書で使われる暦は正式には和暦らしいな。
和暦に対応できないと公的機関では使えないってことらしいぞ。 暦をOSレベルで対応する必要無いやろ
アプリが対応しとれはええ そのアプリの数がですね。Linuxではディストリという名のもとに
たーくさん付属していましてね。基本的にそれらを使うことが前提で
アップデートはディストリ任せなんで、困るんですよ。
もっとOSは基本機能だけにして、
アプリはアプリ単体でアップデート可能にしてもらわないと 日本語変換のmozcだけ対応してけれれば
俺の環境ではオケ 年号による混乱で
Linuxを採用した車両運行スステムが狂って車両同士が正面衝突するするとか
Linuxを採用した携帯スマホ電話のスステムが狂って、電話やメールができなくなったり、
Linuxを採用した銀行スステムで、突然預金残高が10倍になったり、
ってことは全くなかった、ツマラン。 鉄道は時刻秒数は非常に気にしますが日付は必要ありません
モバイルネットワークはグローバルスタンダードなので元号を持ちいりません
銀行も為替が交ってグローバルスタンダードなので元号関係ありません Ubuntu18.04LTSでタスクトレイみたいなとこに令和1って表示できるの?
なんというか平成表記すら選べないのだが そんなのタスクトレイのアプリによるでしょ。
OS自体(厳密にはglibcのロケール定義)はとっくに令和に対応してるから、
あとはデスクトップ環境が和暦を使う仕様になってるかどうかの問題。 問題は連休明けだ
システムが本格稼働し始めると
あっちこっちで火の手が上がって・・・ >>73
最新開発版では対応してるけど、まだ配布されてない
っていうのは、対応のうちに入らない。
実際にエンドユーザーが使えて、初めて対応したと言える。
Ubuntu 18.04は令和に対応していない。 ubuntu配布されてないのか。珍しく保守的だな。
redhatは4月2週目くらいには配布されてたぞ。 楽天銀行は、Linuxの年号スステムのミスが関係しているんですかね 内部で和暦使ってるシステムなんてこの世に存在しないんじゃないの?w 普通は和暦は別個のテーブルに持っておいて、内部のデータは全て西暦。
表示や印字の時に変換するもんだがな。
元データに和暦を入れるのは設計がアホすぎるとしか。 2038年問題はOS関係ないからね。
昔のC/C++で作られたプログラムでtime_tを素直に時刻に使ってるものは全滅だ。
OSよりむしろ家電のファームウェアの被害のほうが大きいのでは? でもGNUはわりとセマンティクスを変更すると思うけど。
セキュリティ上の問題を修正するために同一のシグネチャで関数の動作を変える場合がある。
Microsoftはセマンティクスが変わる場合、シグネチャも変える。 そういえばphpも内部関数に2038年問題に引っかかるのが結構あるな。
非推奨にはなってるけど、ああいうサーバーサイドのインタープリタ言語は長く使われる傾向があるから、
今動いているWEBベースアプリとかは阿鼻叫喚の世界になるんじゃね? >>86
特需年表見て皆ワクテカしながら待ってる。 >>87
今から19年後だぞ?
その頃まだ現役なのか?w >>84
家電のファームウェアはリソースカツカツで作ってるからな。
絶対あると思うわ。
保証期間の1年、もしくは償却期間の5年もてばいいだろって考えで設計しているやつ多いだろうし。
時計(タイマー)機能付きの長持ちする家電は軒並み動かなる可能性がある。
俺の予想では、電気釜、エアコン、TVなんかは半分くらい壊れるんちゃうか?
デジカメやナビも動かなくなるだろうけど、これらはファームウェア更新の手段があるからいいとして、
一番危険なのは公共交通機関だろう。
電車や飛行機などは切り替わる瞬間には乗らないようにしたほうがいいだろうねぇ。
どこにtime_tが使われてるかわかったもんじゃない。
ちなみに切り替わる瞬間ってのは、2038年1月19日3時14分7秒 住信ネット銀行などが今日、障害を起こしたのは、改元のせいか?