マクロの２０００年問題対応について - 秀丸エディタ関連ソフト会議室 - スレッド04527, 1999/11/26

マクロの２０００年問題対応について

Ａｒｉｍａｃ さん　99/11/26 23:37

週間アスキー(12/1)を読んでいたらアメリカでは
２桁の西暦年を４桁の西暦年に変換するのに
５０以上なら1900年代、５０未満なら2000年代とする
方法が特許になっているそうです。（こんなもんが
特許になるなら何でも特許になるぞ・・・）

秀丸エディタではdateキーワードが返してくる値が
２桁の西暦年なのでマクロによっては、やばいかも
しれません。

４桁の西暦年が返ってくるようなキーワードを
追加した方が良いかも知れません・・・

それに今のままでは数十年に一度マクロを修正する
必要が出てくるわけですし、こういった問題に
適切に対応できているとは言い難いと思います。

RE:04527 マクロの２０００年問題対応につ

秀丸担当 さん　99/11/30 18:28

>秀丸エディタではdateキーワードが返してくる値が
>２桁の西暦年なのでマクロによっては、やばいかも
>しれません。

秀丸エディタにある固有の2000年問題は、おそらく
この問題だけです。
新しいキーワードを設けるのも手ですが、既存の
マクロなどはいまの仕様で動いているので、対応
はマクロの修正しかないと思います。

RE:04551 マクロの２０００年問題対応につ

Ａｒｉｍａｃ さん　99/11/30 23:40

>>秀丸エディタではdateキーワードが返してくる値が
>>２桁の西暦年なのでマクロによっては、やばいかも
>>しれません。
>
>秀丸エディタにある固有の2000年問題は、おそらく
>この問題だけです。
>新しいキーワードを設けるのも手ですが、既存の
>マクロなどはいまの仕様で動いているので、対応
>はマクロの修正しかないと思います。

特許侵害しないで対応する方法はあるのでしょうか？
恐らく区切りを５０年から９０年に変えても無駄でしょう（根拠なし）。
秀丸エディタは海外バージョンもあるそうですが、
大丈夫でしょうか？（西暦４桁だったりして・・・）
もっとも、自分はプログラムの修正日付を付けるのに
使っているだけなので今は単に"19"を頭にくっつけている
だけです。来年になったら"20"に変えるだけです（笑）
それとＤＬＬ使えるバージョンになれば、システムから
取ってくれば良いわけですけれど・・・
（今年中に出るのかな？(^^;）
そいえばレジストリに"19"か"20"を入れておくという
方法もありかな？(^^;

RE:04551 マクロの２０００年問題対応につ

EXZS さん　99/12/01 00:14

>>秀丸エディタではdateキーワードが返してくる値が
>>２桁の西暦年なのでマクロによっては、やばいかも
>>しれません。
>
>秀丸エディタにある固有の2000年問題は、おそらく
>この問題だけです。
>新しいキーワードを設けるのも手ですが、既存の
>マクロなどはいまの仕様で動いているので、対応
>はマクロの修正しかないと思います。

　私は新しいキーワードとしてyear,month,day
　などのような個別に数値で返ってくるほうが
　良いのでは？と思います。

　数値ですとその後の変換が楽ですし（西暦や年号など）
　1999.9.19 や 1999/9/19など、日付を加工して
　出力したい場合にむくかと。

　同じことをdate命令を使用して実現している方は
　処理が楽になるので喜ばれるのでは？

RE:04561 マクロの２０００年問題対応につ

秀丸担当 さん　99/12/03 16:55

>　私は新しいキーワードとしてyear,month,day
>　などのような個別に数値で返ってくるほうが
>　良いのでは？と思います。

うーむ。検討しておきます。

RE:04561 マクロの２０００年問題対応につ

Ａｒｉｍａｃ さん　99/12/04 00:05

>>>秀丸エディタではdateキーワードが返してくる値が
>>>２桁の西暦年なのでマクロによっては、やばいかも
>>>しれません。
>>
>>秀丸エディタにある固有の2000年問題は、おそらく
>>この問題だけです。
>>新しいキーワードを設けるのも手ですが、既存の
>>マクロなどはいまの仕様で動いているので、対応
>>はマクロの修正しかないと思います。
>
>　私は新しいキーワードとしてyear,month,day
>　などのような個別に数値で返ってくるほうが
>　良いのでは？と思います。
>
>　数値ですとその後の変換が楽ですし（西暦や年号など）
>　1999.9.19 や 1999/9/19など、日付を加工して
>　出力したい場合にむくかと。
>
>　同じことをdate命令を使用して実現している方は
>　処理が楽になるので喜ばれるのでは？

厳密には日付や時刻の取得は同時性の問題があるので
一度に行なうのが望ましいです(^^;

つまり、yearを取得した時は1999年だったのが、
monthを取得する時には時間が経って2000年になって
しまうと、本来1999年12月又は2000年1月になる筈が
1999年1月というとんでもない日付になってしまいます。
（今でもdateとtimeに別れているので同じ危険性があります）

Visual Basic等がシリアル値として１つの値で日付と時刻を
表現しているのは便利ということもありますが、
こういう理由もあると思います。

リアルタイムシステムじゃあるまいし、そこまで考慮する
必要はないのではないかと言われればそれまでですが・・・
#１００％完璧を目指してもバグがあるのに、まあいいや
#というつもりでプログラムを作っていると間違いなく
#バグだらけになるという信条なもので・・・

RE:04582 マクロの２０００年問題対応につ

EXZS さん　99/12/04 23:18

Ａｒｉｍａｃさん、こんにちは

>厳密には日付や時刻の取得は同時性の問題があるので
>一度に行なうのが望ましいです(^^;
>
>つまり、yearを取得した時は1999年だったのが、
>monthを取得する時には時間が経って2000年になって
>しまうと、本来1999年12月又は2000年1月になる筈が
>1999年1月というとんでもない日付になってしまいます。
>（今でもdateとtimeに別れているので同じ危険性があります）
>

　確かにそうです。
　ただ、どうせ新しい命令後を追加するのですから
　gettimeなる命令を実行した時点の日時を秀丸が
　保持しておいて、次のgettimeが実行されるまで
　常に同じ値が返ってくるっていうのはどうでしょう？
　（ついでにhour,minite,secondも追加したりして）

RE:04586 マクロの２０００年問題対応につ

Ａｒｉｍａｃ さん　99/12/05 00:49

>　確かにそうです。
>　ただ、どうせ新しい命令後を追加するのですから
>　gettimeなる命令を実行した時点の日時を秀丸が
>　保持しておいて、次のgettimeが実行されるまで
>　常に同じ値が返ってくるっていうのはどうでしょう？
>　（ついでにhour,minite,secondも追加したりして）

どうせ秀丸が記憶するのなら、同じ命令が呼ばれた場合は
保持している日時を更新するという方が良いのでは？
（既になってたりして(^^;）
# minite -> minute ですね(^^;
# millisecond があるとマクロの性能を計るのに便利かも(^^;

RE:04587 マクロの２０００年問題対応につ

Ａｒｉｍａｃ さん　99/12/05 13:11

>どうせ秀丸が記憶するのなら、同じ命令が呼ばれた場合は
>保持している日時を更新するという方が良いのでは？

サブルーチンを呼んだり複雑になるとバグりそうな気が
してきたので EXZSさんの方法の方が良いです。
gettimeを呼び忘れる人が出そうなのが気にはなりますが。

RE:04586 マクロの２０００年問題対応につ

ENCODINGSHIFTJIS さん　99/12/06 11:54

とりあえず対応を待てない人用。
内容は　外部からの持ち込み。
--------------------------------
// GetNow.mac
// ほぼ現在時刻をREG経由で取り込み
//
runsync2 "wscript.exe //B REGdatNow.js";
openreg "CURRENTUSER","Software\\Hidemaruo\\Hidemaru\\"+
"Hidemaru.dat";
$s=getregstr("Now");
closereg;
menu $s;
--------------------------------
// REGdatNow.js
// レジストリ Hidemaru.dat に現在時刻を書き込み
// Now=文字列
objDate=new Date();
strNow=objDate.toLocaleString();// MM/DD/YYYY HH:MM:SS
//WScript.Echo(strNow);
Wsh=new ActiveXObject("WScript.Shell");
Wsh.RegWrite("HKCU\\Software\\Hidemaruo\\Hidemaru"+
"\\Hidemaru.dat\\Now",strNow,"REG_SZ");
-------------------------------
議論の本流とは少し違いますが。
◆