和暦で省略形の心配

Question

和暦の年号が一桁のアルファベットで表せると仮定するのは無理があるように思うのです。今はM,T,S,Hとなっていますが、改元で例えば明和という年号が付いたらMWと省略されるのではないでしょうか。漢字一文字も無理がありますね。

http://msdn.microsoft.com/ja-jp/library/system.globalization.japanesecalendar%28v=vs.95%29.aspx

アプリケーションで JapaneseCalendar クラスを使用している場合、DateTime.Parse は年の前に表記される時代 (年号) の省略形を認識します。この省略名は、大文字と小文字を区別しないローマ字 1 文字の省略形または漢字 1 文字の省略形のいずれかです。

---

http://systemartlaboratory.com/

Answer 1

Excelなんかも同様ですね。漢字にしてもアルファベットにしても省略して一文字で表すことは世間一般に浸透していますから、そこがダブらないように次の元号が決まると思っていますが、こればっかりは確かにわからないですね。ただ、省略一文字が世間一般に浸透していることから、今のところはJapaneseCalendarクラスでもそれに従って対応するのは仕方のないことだと思います。JapaneseCalendarクラスの問題というよりは、世間一般で省略一文字が通用しているという状況の問題のような気がします。

---

★良い回答には回答済みマークを付けよう！ わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

Answer 2

コメントありがとうございます。

「ダブらないように次の元号が決まる」

実際のところどうなんでしょうね。配慮しているのでしょうか。そうあって欲しいですが。

世間一般に浸透しているのは、区別可能な最も短い文字列に省略することではないでしょうか。現在はたまたま一文字で区別可能なので一文字に省略していると考えています。区別できなければ文字数を増やすというのは自然な発想だと思います。

私はJapaneseCalendarクラスで一文字と明記しない方がよいと思うのです。改元があって２文字必要になればJapaneseCalendarクラスもそれに対応するでしょう。NetFrameworkのソースを見たことがありますが、一文字にしか対応できない書き方はしていなかったと記憶しています。

でもJapaneseCalendarクラスで一文字を明記している状況ではアプリケーションはそれを前提に処理を書いてしまうかもわかりませんし問題が大きくなると思うのです。１文字と明記しない方がよいのではないでしょうか。

---

http://systemartlaboratory.com/

Answer 3

あくまで個人的な感想ですが、アルファベットは１文字だから省略形として機能しているように思います。２文字になるとパッと判断が付きにくくなり、あまり使われなくなっていくような気もします。原則的には２文字でも重なる可能性がありますし、かといって３文字になると余計に難しくなり、もはや省略形として本来の機能を失うのではないかと思います。

＞でもJapaneseCalendarクラスで一文字を明記している状況ではアプリケーションはそれを前提に処理を書いてしまうかもわかりませんし問題が大きくなると思うのです。１文字と明記しない方がよいのではないでしょうか。

1文字と明記しなければ、複数文字を考慮して処理を書くのだろうか？という疑問はあります。JapaneseCalendarクラスの仕様として1文字というよりも、世間の常識として言われなくても省略形は１文字という知識で判断して処理を書くことが多いのではないかと思います。つまり、JapaneseCalendarクラスに1文字が明記してあることは、三輪の牛さんが心配されている1文字を前提で処理が書かれてしまうことにほとんど影響しないように思います。
よって、三輪の牛さんが心配されている1文字を前提で処理を書かれることを避けるのであれば、例えば明に「将来、省略形は２文字以上になるかもしれません。」と注意を促した上で、現在の仕様の説明として、1文字は明記してもかまわないと思います。一方で、１文字の明記はほとんどの人にとって常識なのでさらっと読み飛ばし、深く考えないのである意味蛇足に近いと思いますから、無くてもかまわないとも思います。 

---

---

★良い回答には回答済みマークを付けよう！ わんくま同盟 MVP - Visual C# http://d.hatena.ne.jp/trapemiya/

Answer 4

JapaneseCalendarに一文字と書かれていなければ複数文字の可能性を考慮する方がどの程度おいでかどうか私には判断が付きません。私は書かれていても考慮しましたが。

明に「将来、省略形は２文字以上になるかもしれません。」と注意を促すのが良さそうですね。

---

http://systemartlaboratory.com/

Answer 5

1 文字であるという断定を削ることはやっても良さそうと感じられる範囲ですが、2 文字以上になること明示するのはやり過ぎな印象です。
将来は誰にもわからないことですし、悪い見方をすれば「不吉なこと」を示唆しているようにも見えますし…。

この問題に限らず、アプリの設計によっては改元で大規模修正が必要になるかもしれませんね。
将来を考慮するよりは市場に出すスピードを優先して割り切る判断なんて山のようにされている世の中ですし、この文言を削ることによって、耐えられるソフトウェアが増えるとは思っていません。
ただ、どちらがよりベターかと言われれば、”確かな法則がない断言（1 文字であること）を削ること”という意味で、冒頭の「削ることはやってもよさそう」という見解になりました。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 6

コメントありがとうございます。
表現が直接的過ぎかもわかりませんね。
＞ローマ字による省略形または漢字 の省略形のいずれかです。どちらの場合も１文字とは限りません。
くらいでしょうか。
＞冒頭の「削ることはやってもよさそう」という見解になりました。
あのすみません。Azuleanさんの個人的見解でしょうか。それとも仕様を話し合う組織か何かがあってそこでの見解でしょうか。
Azuleanさんてマイクロソフトの人ですか。

---

http://systemartlaboratory.com/

Answer 7

こんにちは

JapaneseCalendarクラスの仕様で明記してしまっていることについて、
法律で「元号省略形」を規定されていない限り、明記は控えるべきかと
私も同感です。

あくまで私の勝手な予想見解でしかありませんが、
元号省略形自体はコンピュータの世界だけにとどまらないことで
社会はどんな元号になろうと１文字にすると思います。
明和ならEなどとする気がします。
ちなみに東京の地下鉄の半蔵門線で、省略記号が[Z]、という事例があります。

ローマ字の先頭から拾わねばならぬと規定されていることでもない上
年号は非常に頻繁に使用するものですから、元号にゆかりがあって判別できる１文字が使われるでしょう。
(あなたにそんなこと言えるんですか？と、もし私の文章と文意をよく読んでいただけない方から問われてしまえば、もうお答えのしようがないですけど...)

皇室や宮内庁の方は、
不敬であるとか、そんな心の狭いことはおっしゃらないと思いますね。

Answer 8

私の書き方がまずったようです。
（冒頭に私の意見を先に書き、過程を書いた上で結びとして私の意見を再度書いたものでした)

「見解」は「私の個人的な見解」の意味ですし、私はマイクロソフトの関係者でもありません。

直接は関係しませんが、マイクロソフトの社員の方が
書き込まれることがあったとしてもそれはその社員の個人的見解にとどまり、会社や部署としての見解にはならないと明言されていますね。
http://www.microsoft.com/ja-jp/communities/msp.aspx

今回のような、ドキュメントに対して改善を促すのは各ページの評価機能からコメントを寄せるやり方になります。

# 出先なので文面があまり練れてません。

---

質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。

Answer 9

Azuleanさん、妙な詮索をして済みませんでした。

Connectにしようと思ったのですが、そのようなやり方もありましたね。

了解しました。

---

http://systemartlaboratory.com/

Answer 10

koma_dekoさん、コメントありがとうございます。

大阪市営地下鉄にもありました。堺筋線 Ｋ線。

そういう決め方もありますね。

明記を控えるべきとのこと了解しました。

 

---

http://systemartlaboratory.com/

Answer 11

すいません・・・明記されていて何が問題なのでしょう？

.NET Framework はあくまで Microsoft社 が体系化した Framework な訳ですし、省略文字が M,T,S,H である事も

極端に言えば Microsoft社の仕様と言い換えられるのではないでしょうか。

 

三輪の牛さんの見解は、例えば次の元号が何だとしても、それに伴う省略文字を世間一般と合わせる責任をMicrosoftに求めている様に感じます。

確かに合わせてもらわないと開発者には使いにくい事この上ないですが、それはちょっと無理があるのではないでしょうか。

 

個人的な見解としてですが、MSDNライブラリはMicrosoftによる仕様説明と解釈し、

「現状このような仕様になっています。」と受け取るのが妥当なのではないでしょうか。

Answer 12

aviator_さん、コメントありがとうございます。

私は省略形を世間一般と合わせることをMicrosoftに期待します。

現状の仕様説明としてはおっしゃるとおり問題ないと思います。

改元で仕様変更になりましたというよりは、仕様に幅を持たせる方が良いと思います。

 

---

http://systemartlaboratory.com/

Answer 13

＞すいません・・・明記されていて何が問題なのでしょう？

世間で2文字以上の略記になっても
Parse関数が文字列を解釈する都合などから、Microsoftさんは1文字のままにするおつもりかもしれません。

が、もしMicrosoftさんがそれに倣って2文字以上採用したら
仕様変更になりますので...明記されていなければ仕様変更にはならない。

端的に言えば、そのときは改修が入って大変なだけです。

「猫を電子レンジで乾かさないでください」と同じレベルのことかもしれませんけれども、
日本国の元号事情をよく知らない外国の方がオフショア開発されることは何も珍しくないですから
C言語的にいえば char や char[1] で使いまわすプログラマさんもおられるんじゃないでしょうか？
(穿っていえば、仕様変更⇒改造・予算どり、で立場によってはオイシイかもしれませんけれども)
と考えました。

なので、三輪の牛さんのご意見は
細かいかもしれませんが確かにごもっとも、と私は思った次第です。

とはいえ、改元は将来のことであり
Microsoftさんが提示されている仕様書(Document)は、現状の実装(動作)と食い違いがあるわけでもありませんから、
あくまで「もしも」の話ですね。

Answer 14

koma_dekoさん、ありがとうございます。

Netframework4について、２文字以上をParseするかどうか確認したのですが、ちゃんとパースします。

レジストリをいじって、例えば最後の行は_Hとなっている物を_HEとしたらHEを年号として解釈してくれます。

表示もこのレジストリを使っていますので漢字年号の部分を変えたらそれに従って表示してくれます。

 

 

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]
"1868 01 01"="明治_明_Meiji_M"
"1912 07 30"="大正_大_Taisho_T"
"1926 12 25"="昭和_昭_Showa_S"
"1989 01 08"="平成_平_Heisei_HE"

Netframework4だけの問題ではないので、これだけでは済まないと思いますが。

皆さんにいただいた意見を参考にフィードバックします。

一人で考えるより良いフィードバックができそうです。

後はマイクロソフトに下駄を預けようと思います。

ありがとうございました。

 

---

http://systemartlaboratory.com/

Answer 15

三輪の牛さん：
MSDN のコミュニティ コンテンツに書き込みされていますが、あそこに「避けた方がよいのではないでしょうか」のような、マイクロソフトへの提案は、ふさわしくありません。コミュニティ コンテンツは、他のユーザーへの助言を書く場所ですので、例えば次のような書き方の方が良いと思います。今書いてある内容は、ページの最下段あたり、「フィードバック」から投稿するとよいと思います。

年号省略形　１文字に限定されない

＞アプリケーションで JapaneseCalendar クラスを使用している場合、DateTime.Parse は年の前に表記される時代 (年号) の省略形を認識します。 この省略名は、大文字と小文字を区別しないローマ字 1 文字の省略形または漢字 1 文字の省略形のいずれかです。
この部分ですが、今後、年号がアルファベットや漢字１文字で判別可能であるとは限りません。また、.NET Framework 4 では、以下のレジストリを変えて２文字以上にしても動作するのは確認しています。「省略形として、1文字しか認識されない」わけではありません。
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras]
"1868 01 01"="明治_明_Meiji_M"
"1912 07 30"="大正_大_Taisho_T"
"1926 12 25"="昭和_昭_Showa_S"
"1989 01 08"="平成_平_Heisei_H"

# 私は、コミュニティ コンテンツ立ち上げ時に、モデレーターとして、編集の判断基準について説明を受けています。その基準から、編集した方がよいと考えます。

---

Jitta＠わんくま同盟

Answer 16

ありがとうございました。

コミュニティ コンテンツではフィードバックにならないのですね。

下記URLを参考に電子メールで送りました。

 

http://msdn.microsoft.com/ja-jp/vstudio/cc789294

 

---

http://systemartlaboratory.com/