.NET Frameworkに新たな新元号対応機能が追加される 46
ストーリー by hylom
現実的な対応 部門より
現実的な対応 部門より
あるAnonymous Coward曰く、
.NET Frameworkに新たな新元号対応機能が追加される（日本マイクロソフトのJapan New Era Name Support Blog、窓の杜）。
1）.NET Framework ver.4系に先行実装されたレジストリによる元号判定が、.NET Framework ver.2.0～3.5にも実装される。
2）昭和65年や平成32年といった正規化されていない元号の日付であっても、正常に西暦に変換できるようになる。（これまでは例外が発生していた。）
3）上記動作の変更に伴って、旧来の動作と新しい動作とを切り替えられる設定を追加。
面倒なことをしてくれるものである。
1）の仕様変更は7月の月例アップデートで提供され、2）変更については6月末の更新で「Optional」として配信されるが、「重要な更新」にこの変更を含める時期は未定という。
免許証の期限とか (スコア:3, 興味深い)
＞昭和65年や平成32年といった表現は、法令上無効なものではなく
あーそっか、免許証の期限とかで実際に使われてるから、対応してないと困るのか。なるほど奥が深い。
Re:免許証の期限とか (スコア:1)
Javaの方の新元号対応状況 [hatena.ne.jp]
正規化？されていない元号に対しては今の所例外になってしまう模様。
> 元号に関わる処理は日本向けシステムを作っている人にしか影響がないので、日本で声をあげないと改善はされません。
> 元号を扱う可能性があるなら、動作を確認して声をあげていかないといけないと思います。
Re: (スコア:0)
思うにもっと早くに声を上げるべきだったと。ジャバはオープンな仕様なのでね。
まあ使用はオープンだがオラクルの説得には金かマンパワーの供出が必要になるが。
Re: (スコア:0)
こういう事があるんだぁ。
Re: (スコア:0)
今年のカレンダーもこういう表記になってる
Re: (スコア:0)
昭和65年が通るようになるとシステムに「昭和65年」のデータを入力して確かに受理されたはずなのに
後日「昭和」で検索しても入力したはずのデータが出てこない、みたいな案件が……
Re: (スコア:0)
それはそれで正解のような。
「平成」で検索して昭和65年のデータが出てこないのも不便だし、
出てくるようにすると、「昭和」と「平成」検索すると重複することになる。
次は (スコア:0)
12/32や3/32への対応をお願いします。
Re: (スコア:0)
それは今でも正規化されるよね？
それともなんか投げろってこと。
・石を投げる
・匙を投げる
あとなんだ。
Re:次は (スコア:1)
身を投げる？
Re: (スコア:0)
身を投げる？
まずは賽を投げてからにしようぜ
Re:次は (スコア:1)
Re: (スコア:0)
PowerShellでのテストだけど、DateTime.Parseで例外発生するよ？
Re: (スコア:0)
このへんな日付は ときどき日本にいるのです。たぶん。
主に進捗が芳しくないプロジェクトとかに。
Re: (スコア:0)
.Netでなく、VBS/VBA/Excel/Access等のDateSerial 関数 [microsoft.com]でやってみてください。
PowerShellで確認したいなら必ずWSHが呼べるx86版で、下記のコードをどうぞ。
悍ましいものが見れます。
$obj = New-Object -ComObject "MSScriptControl.Scriptcontrol"
$obj.Language = "VBScript"
$obj.Eval("DateSerial(2018,12,32)")
Re: (スコア:0)
元のストーリーが元号に関するものなんだから、処理内容は文字列から日付への変換だということがなんで分からないかな。
この場合はDateSerialじゃなくてCDate。
$obj = New-Object -ComObject "MSScriptControl.Scriptcontrol"
$obj.Language = "VBScript"
$obj.Eval("CDate(""2018/12/31"")")
# 2018年12月31日 00:00:00
$obj.Eval("CDate(""2018/12/32"")")
# HRESULT からの例外:0x80020101
# 発生場所 行:1 文字:1
# + $obj.Eval("CDate(""2018/12/32"")")
# + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# + CategoryInfo : OperationStopped: (:) [], COMException
# + FullyQualified
なにをもって面倒といっている？ (スコア:0)
理想に近い仕様変更では？
Re:なにをもって面倒といっている？ (スコア:1)
いや、平成32年とかより、明治5年の改暦以前の和暦変換をちゃんと実装してほしい。
明治元年閏卯月三日（慶應義塾が三田に出来た日）とか。
Re: (スコア:0)
天保暦だけに対応すればいいって訳でもないのでキリがない
# ユリウス日から算出するのを考えましたが挫折しました
Re: (スコア:0)
.NET Framework ver.2.0までバックポートとなるとテスト
工数を考えると頭痛が痛くなる人はいるかもしれない。
4以上か、せめてWin7に載ってった3.5までにしてほしかったかも。
Re:なにをもって面倒といっている？ (スコア:1)
そこまでアップデートされて困るならそもそもアップデートを止めた方がいいのでは。。。
Re:なにをもって面倒といっている？ (スコア:1, 参考になる)
ソース読めばわかるが、3.5以前への変更はOptionalだから心配ない。
Re: (スコア:0)
3.5は2.0以上を包括しているから、3.5固有の機能以外は2.0対応=3.5対応
Re: (スコア:0)
2.0と3.5は動作環境が同じなのでしょうがない
2.0と3.5はCLRのバージョンが同じで
3.5環境で2.0で作ったソフトが動くので
Re: (スコア:0)
既定が従来の動作でない点と4.5.2以前の動作をプロセスごとに変更できない点が残念
Re: (スコア:0)
仕様変更だからあかん。
仕様変更のおかげで以前はエラーで転けてたアプリがちゃんと動くようになった! やったね! みたいなのは、趣味の日曜プログラミングぐらいでしかあり得ない。
変なのを食わせても西暦に変換してくれる関数を別途追加すれば良かった。
Re: (スコア:0)
やっぱりこれ元号発表しない政府（とそんな政府を支持する愚民ども）に対する嫌がらせでしょ。
Re: (スコア:0)
昭和65年がエラーになる仕様をどうしても維持したいのなら、AppConfigに設定を追加する必要があるが、たいした手間でもなかろう。
大半のシステムは、今回のMicrosoftの対応のおかげで、ソースコード変更なし、再テストのみで済むのではないか。
Re: (スコア:0)
じゃあ、AppConfigに設定を追加するだけで済んだぁ! やったね!
から、どうやって、新たに追加された「はみ出た入力でもきちんと変換できる機能」を使うプログラムに移行していくおつもりで?
どこに設定を追加しなきゃならないかを調べようとしたら、どうせ、全ソースに全文検索かけるような手間が必要なわけで、そこで新APIへ置換してしまっても手間は変わらない。
Re: (スコア:0)
AppContext に値を設定するだけなら
> どこに設定を追加しなきゃならないかを調べようとしたら、どうせ、全ソースに全文検索かけるような手間が必要なわけで、そこで新APIへ置換してしまっても手間は変わらない。
とかいった手間は別に必要ないような．
4.5.2 以前向けのレジストリへの設定も，ソースのリンク先見るだけで判りますよ．
Re: (スコア:0)
こいつプログラム書いたことないだろ
Re: (スコア:0)
「そんなローカルの古臭い風習までいちいち面倒見るわけがねえだろうがボケェ！西暦を使え！！どうしても使いたいなら自分で実装しろ！！！」って言って、西暦以外に対応しないのが普通の社会を作る後押しをしてくれるのが理想
Re: (スコア:0)
元号発表を直前にすることで西暦の後押しをしようとした（◎本会議談）
2.0/3.0は変更されないよね？ (スコア:0)
リンク先本文読むと、3.5の現行の動作の解説として、2.0/3.0も同様の動作であると書いてあるのみであって、
更新の対象は3.5だけで、2.0/3.0は含まれないよね？
Re: (スコア:0)
別ツリーのコメントにもあるけど、2.0～3.5のランタイムプログラムは同じもの。
しかもこのランタイムの年号処理は「モジュール内にハードコーディングしてある」ということなので、3.5のみ変更の方が無理っぽい
VB6やVBAやVBScriptは！ (スコア:0)
どうなってんの！
まだ死滅してないので、対応があるのか、あるいは無いのかぐらいは知りたいのだけど。
おそらく対応しないんだろうな、とは思うのだけど、公式な発表があるかないかは大違いなので…。
VBAについてはOfficeが対応すれば対応するのかな。
Officeの対応状況も知りたい所なんだけど、発表しないのだろうか。
Re:VB6やVBAやVBScriptは！ (スコア:3, 参考になる)
4月に新元号に対応に関する各プロダクトの対応状況等についてセミナーがあったそうで
(今後もあるとは思いますが・・・)
https://blogs.technet.microsoft.com/mpn_japan/2018/04/12/readiness-for... [microsoft.com]
参加した方のレポートがQiitaにあります。
https://qiita.com/You_name_is_YU/items/3f6f9825c2d1c97c5ea6 [qiita.com]
質問にてVB6周りも質問が出たようですが、
・ランタイムは現行サポートOSに組み込まれているものは対応範囲内
・VB6そのものはサポート終了により対象外
との回答のようですね。
Re: (スコア:0)
マイクロソフトが追加しないのであれば、一般ユーザー同士でCP932のどこに新元号の合字を追加するのかのコンセンサスを得たいです。
Re: (スコア:0)
一般ユーザー「CP932ってなにそれおいしいの」
Re: (スコア:0)
無理言うな。外字領域を使い倒しているユーザがどれだけいるのか考えてみろ。
Re: (スコア:0)
情報ありがとうございます。
VB6ランタイムはOS依存ということは、当面はサポートされるってことですね。
Format(来年, "ggge")で新元号が出るし、CDate("新元号1年5月1日") はエラーにならない、と期待して良いのかな。
一方、VB6のIDEはサポート外、ってことは、IDE上で実行するとエラーになるのかな。
※OSにインストールされているランタイムに依存するならエラーにならない？
VBScriptに関してもOSに依存しそうなので、現役のOSなら大丈夫そうですね。
いずれにせよ、公式で発表して欲しい所です…。
Re: (スコア:0)
そも、VB 6.0 IDEはXP 32bitが最後なんで現行OSでは開発出来ない(事になっている) [microsoft.com]
Re: (スコア:0)
Windows7の32bitがあるじゃん。これはIDEのサポート内だったはず。
とはいえ、実際は64bitでも開発できちゃうけどね。
使うなと言われても、メンテもあるからねぇ…。
ランタイムが動く限りは、VB6のアプリもなくならなそう。
Re: (スコア:0)
Win10の来年以降のどっか時点のアップデートでランタイム使えなくされそう...。
Windows7は？ (スコア:0)
Windows7のWindowsUpdateも用意されるの？
これで新元号が標準で使えないようなフォントだったら (スコア:0)
工数たくさん貰えるかなぁ・・・