2000年問題

[上に] [前に] [次に]
わいるどあむ 1999/09/07(火) 17:32:05
みなさん、はじめまして。
早速なんですが、Ｐｅｒｌのプログラムにおいて
２ＫＹ対応使用としてます。
いまのところ、時間をtimelocalにて取得しているのですが、
取得する年数は2桁なので、９９なら＋１９００、以外は＋２０００
みたいな感じで考えているのですが、
もっとよい方法ありますか？
年数を4桁で返す関数探したのですがありませんでした。
なんかこの感じだとあまりカッコ好くないような気がして・・・
また、他にもＰｅｒｌでプログラムにおいて２ＫＹで
この辺を気を付けた方がいい。みたいなところがあったら、
教えてください。
（ソースや環境によると思いますが、
  ざっくばらんにこの辺大丈夫なの？
  みたいなのがあればよろしくお願いします。）
かなりアバウトな質問で申し訳ありません。
あのんきい 1999/09/07(火) 17:45:03
注意点としてですが、OSがWindowsの場合は、
わいるどあむさんの書き方でよいのですが、
UNIXの場合は、2000年は'100'となるので、注意が必要です

CGIとかでPerlを使用している場合は、サーバのOSがUNIXである可能性が非常に高いので
気を付けましょう(^^ゞ
ふじ 1999/09/07(火) 18:10:02
＞注意点としてですが、OSがWindowsの場合は、
＞わいるどあむさんの書き方でよいのですが、
本当？？
Windows NT4.0(SP3) + ActivePerl519 で、システムの日付を2000年にして
@_ = localtime(time);
としたら、
$_[5] == 100
になりました。

青ラクダ本にも、localtime の説明で、
＞$yearは1900が引いた値がセットされているので注意すること
という記述があります。

単純に +1900 でいいのでは。
あのんきい 1999/09/07(火) 18:26:15
失礼しました
私の勘違いです

Windows(98)でも"+1900"で良いようです(-_-;)
わいるどあむ 1999/09/07(火) 18:31:00
おはやいレスありがとうございます。
ＯＳはＵＮＩＸ（Ｓｏｌａｒｉｓ２．５．１）
Ｐｅｒｌ５です。
やはりlocaltimeは駄目ですね。
年数を４桁で取得する方法はあるのでしょうか？
ふじ 1999/09/07(火) 20:15:06
＞やはりlocaltimeは駄目ですね。
何故？？？

＞年数を４桁で取得する方法はあるのでしょうか？
$year += 1900;
で何か問題あるんでしょうか。
杉山 1999/09/07(火) 21:38:59
すみません。便乗質問です。
現在Windows95＋ＩＥ4.0プラスサービスパック２
を使っているのですが、2000年問題で何かしなければいけないですか？
マイクロソフトのページを見ましたが、システムに変更を加える
ようなので少し怖いです。ハードディスクの残りも
100メガしかないし。
みなさん、どうしてますか？

「杉山さ〜ん、私のコンピュータ、2000年問題大丈夫ですか？」と
ある初心者に聞かれて、「あんたは2000年が来る前に、
まずファイルのコピー＆ペーストが出来るようになりなさい」と
冷たく言い放った私ですが、なにを隠そう、私自身が初心者
なのでした。
B-Cus 1999/09/07(火) 22:45:49
> 2000年問題で何かしなければいけないですか？
少なくとも、そーゆーWindows一般のことは、ここで
聞くべきではないと思うんですが。聞くなら
　http://www.so-net.ne.jp/ClubHouse/room/pc_scramble_win/pc_scramble_win.html
とか。
杉山 1999/09/07(火) 23:19:17
失礼しました。
Windows一般のことを聞くところがあったんですね。
とほほ 1999/09/07(火) 23:40:50
という訳で、本題の件ですが、Perlでは、$year += 1900; とすること
で2000年問題を回避することができます。

問題なのは、JavaScriptのgetYear()だな。
わいるどあむ 1999/09/08(水) 10:19:12
[[解決]]
おはようございます。

ふじさんへ
＞$year += 1900;
＞で何か問題あるんでしょうか。
いえ、問題はありません。
プログラムの中でちょっと面倒な事をしているので、
できたら、４桁で欲しいなというだけです。
でも、私はうっかりしていて２０００年は０を
返すと思っていたのですが、１００を返すという事なので、
$year += 1900;でぜんぜんＯＫです。（変な日本語？）

みなさん、Ｐｅｒｌで他にも注意点などありましたら
お願いします。
今のところ調査では、ここぐらいでプログラム的には
大丈夫だと思っています。

まぁ、こんだけ騒いでおりますが２０００年よりも、２０３８年
の方がもっとすごいことになりそうですね。
やも [HomePage] 1999/09/08(水) 23:43:01
その、2038年に一体何が起こるのかちょっと、知りたいです。
符号付き32bitなUNIX時間があふれる？んですよね。ところが「Solaris7 の time_t は 64bitになっているから大丈夫」と聞きかじりました。2032年に何事もないＯＳということですよね。このような「大丈夫なヤツ」、他にもたくさん居たりするんでしょうか。例えば、linuxとか・・・ Webサーバにも影響でるんでしょうか。
B-Cus 1999/09/09(木) 01:29:51
UNIXの偉い人に聞いてきた。

基本的には
　typedef long time_t を typedef long long time_t に変える
でOK。ただし、それなりのカーネルの修正も必要。

また、sizeof(time_t)==4とか、sizeof(time_t)==sizeof(int)を
仮定しているアプリ、つまりtime.hをincludeしてtime_tを使わなきゃ
いけないのに、intを使ってるようなお行儀の悪いアプリは修正が必要。
ただ、これは time_t が 64bit な Solaris7 でも同様(ちなみにSolaris7
でもintは32bit)。

ファイルシステムのタイムスタンプが32bitを前提としている
ので、ファイルシステム(FFS)が変わるかも。これは結構厳しい。

本質的には上のと同じだけど、4バイトで済んでたところが8バイトに
なるので、各種データの互換性がなくなる場合があるかも。

NFSは32bitを仮定してるので、困ったことに。

だそうで。

個人的には、39年後のことなんか知らん、です :-)
そのころUNIXやMacやWindowsが存在してるんでしょうかね〜。
やも [HomePage] 1999/09/09(木) 06:30:59
なるほど、・・というか分からないのでログ保存しときますわ(笑)
ありがとうございます＞B-Cusさん。
> そのころUNIXやMacやWindowsが存在してるんでしょうかね〜。
「昔はフリーズなんてものがあってのう・・・」なんて・・・
そもそもＯＳという概念自体がなくなってたりして。
[上に] [前に] [次に]