2001年9月9日問題
Takayuki Iwaasa
UNIX系で2001年9月9日問題
（1970年1月1日0時0分0秒を起点とした
システムタイムに絡む問題）
がありますが、Windows系でも同様の
問題が発生するのでしょうか？
ポインタでも構いませんので、
教えてください。
宜しくお願いします。
Kazuo Fox Dohzono
Takayuki Iwaasa <Takayuk...@yokogawa.co.jp> writes:
> UNIX系で2001年9月9日問題
> （1970年1月1日0時0分0秒を起点とした
> システムタイムに絡む問題）
> がありますが、
ないでしょう.
気になって調べてみましたが, 1970/01/01 00:00:00 からの (閏年を考慮して
閏秒は考慮しない) 経過時間では
2001/09/09 00:00:00 (0x3b9ab100 = 999993600 秒)
2001/09/09 23:59:59 (0x3b9c027f = 1000079999 秒)
ですが, どちらも 32bit 符合付き整数で保持可能な値です. 問題なのは
2038/01/19 03:14:07 (0x7fffffff = 2147483647 秒)
の次の秒だと思います.
--
Kazuo Fox Dohzono / doh...@hf.rim.or.jp
[12],(6,9),0,0,2
(4/1449/3742)
Takeshi SHIGIHARA
>
> UNIX系で2001年9月9日問題
> （1970年1月1日0時0分0秒を起点とした
> システムタイムに絡む問題）
> がありますが、Windows系でも同様の
> 問題が発生するのでしょうか？
http://bizit.nikkeibp.co.jp/it/y2k/about/non-y2k.shtml によれば、
秒を１０進数で表記する場合に、GMT/UTC 2001年9月9日午前1時46分40秒
を境に１０進９桁から１０桁に増えるのですが、その１０進数を固定桁数
で操作している場合に起こり得る問題とされています。
<9a0rc3$5q1$1...@news2.rim.or.jp> で Kazuo Fox Dohzono さんも計算されて
いらっしゃいますが、
> 2001/09/09 00:00:00 (0x3b9ab100 = 999993600 秒)
> 2001/09/09 23:59:59 (0x3b9c027f = 1000079999 秒)
１０進で見ると、確かに桁が増えていますね。
わざわざ、秒を１０進数に変換しているようなアプリケーションでは同様の
問題が起こり得ますが、Windowsシステム内部では３２ビット数として秒を
管理していますから、起こらないタイプの問題です。
----- Takeshi SHIGIHARA
Office cyg...@zero.ad.jp
Home cyg...@po.jah.ne.jp -----
Takayuki Iwaasa
その「ブツ」なのか分かりませんが、以下のWEBが公開されています。
1.富士通
http://www.fujitsu.co.jp/jp/soft/btrend/2000/ds/hb2000-12.html
2.日立
http://www.hitachi.co.jp/Prod/comp/soft1/9-9problem/index.html
Kazuo Fox Dohzono wrote:
> In article <9a0rc3$5q1$1...@news2.rim.or.jp>
> doh...@hf.rim.or.jp (Kazuo Fox Dohzono) writes:
>
>
>> 32bit 符合付き整数
>
>
> でなくて bcd で保持してるブツってあるんですか? (ありそうな気もしてきた…).
S. GOTO
news:3AC3CE1C...@yokogawa.co.jp...
> 岩浅＠横河電機と申します。
>
> UNIX系で2001年9月9日問題
> （1970年1月1日0時0分0秒を起点とした
> システムタイムに絡む問題）
> がありますが、Windows系でも同様の
> 問題が発生するのでしょうか？
この問題の本質は、
GMT/UTC 1970年1月1日0時0分0秒からの経過時間を秒数で表示する場合、
GMT/UTC 2001年9月9日午前1時46分39秒 ( 999999999)
↓
GMT/UTC 2001年9月9日午前1時46分40秒 (1000000000)
と、桁数が９から１０に増えることにより生ずる問題と認識しています。
つまり、表示桁数を９桁固定にすると
000000000→GMT/UTC 1970年1月1日0時0分0秒
と同じになってしまう、ということです。
表示されている秒数から値を取得する、ということをしているプログラムは
問題があります。
ですから、時間を符号付き３２ビット整数型で表現するＯＳには
共通の問題と思います。
> ポインタでも構いませんので、
> 教えてください。
解説だけですけれど
http://bizit.nikkeibp.co.jp/it/y2k/about/non-y2k.html
--
S. GOTO
mailto:goto.sh...@lab.ntt.co.jp
MOCHIDA Shuji
持田＠NETside です。
> GMT/UTC 2001年9月9日午前1時46分39秒 ( 999999999)
> ↓
> GMT/UTC 2001年9月9日午前1時46分40秒 (1000000000)
10 億秒問題!?
> ですから、時間を符号付き３２ビット整数型で表現するＯＳには
> 共通の問題と思います。
符号無し 32bit にしても、64bit にしても解決しませんね。
＃ 16bit の OS には無い問題だ、ってことかな?
蛇足:
y2k にしてもそうだけど、「その頃まで使うの想定しないで作った」ん
だったら、その主旨を通して、_使うのやめればいい_ のに、って
思うのは、私だけ?
--
持田 修司 NETside Technologies Inc.
-- Do not crack your dream. Be MI by NetBSD --
Kazuo Fox Dohzono
Takayuki Iwaasa <Takayuk...@yokogawa.co.jp> writes:
> 1.富士通
> http://www.fujitsu.co.jp/jp/soft/btrend/2000/ds/hb2000-12.html
こちらはアクセスできませんでした.
> 2.日立
> http://www.hitachi.co.jp/Prod/comp/soft1/9-9problem/index.html
こちらはアプリケーションの問題で UNIX それ自体ではないように見えました.
# この場合「UNIX 系」ってのは「UNIX 上に構築されたシステム」のことなの
# ね.
Eiji Kawakita
<9a1hro$he9$1...@news2.rim.or.jp>の記事において
doh...@hf.rim.or.jpさんは書きました。
># この場合「UNIX 系」ってのは「UNIX 上に構築されたシステム」のことなの
># ね.
http://www.merlyn.demon.co.uk/critdate.htm#n18
によれば、Digital Unix自体のバグがある様ですね。
(On the "documentation CD-ROM that came with Digital Unix 4.0D"; other
Y2k errors were also fixed.) ということなのでDigital unix 4.0Dよりまえ
のバージョンの話と思いますが正確な問題のバージョンはよく分かりません。
＃しかし、これもY2K問題って言っていいのか凄く疑問なんですけどね。
＃2000年近辺の時間に関する問題は全てY2Kって言ってるような気がします。
--
☆これにて失礼つかまつる。
川北英治＠広域仁侠団体苺組 舎弟頭
Email:a...@daio.net
Email:a...@cyber.email.ne.jp
電子のお針箱
news:ul866gr...@pine.yorie.netside.co.jp...
> 蛇足:
> y2k にしてもそうだけど、「その頃まで使うの想定しないで作った」ん
> だったら、その主旨を通して、_使うのやめればいい_ のに、って
> 思うのは、私だけ?
普通作った人と、その頃に使っている人が違うと思いますが...。
--
---------------
電子のお針箱
ue...@di.mbn.or.jp
---------------
Masamichi Takatsu
以前(3月末)、2001年9月9日問題(1970年1月1日からの秒数が9桁から10桁になる)
がちょっと話題になりました。
私は当時、「そんな問題起こすようなプログラムは普通書かんよなぁ」
と思っていたのですが、みごとにやってしまいました。
perl で書いた、ファイルを日付順にソートしているような CGI だったのですが、
比較を <=> ですべき所を cmp でやってたんです。そのため、9/9 10:46以降の
ファイルが一番後ろに並んでしまいました…
普通に日付順に並べ替えるならこういうボケはしなかったと思うのですが、
いろいろなソート条件の一つに日付順というのがあり、cmp しているソート
ルーチンで対象データだけ差し替えたため、こういう問題が起きてしまいました。
というわけで、そういうアホも居たという報告です…
PROJECT TEAM ＤｏＧＡ 高津正道 ta...@doga.jp
TBD0...@nifty.ne.jp
PROJECT TEAM DoGAのホームページ → http://doga.jp/
9月10日(月) 今日のマーフィーの法則 [レインによる、パーキンソンの法則の応用]
所有物は、使用可能な収納スペースを満たすまで増加する。
candy
> 以前(3月末)、2001年9月9日問題(1970年1月1日からの秒数が9桁から10桁になる)
> がちょっと話題になりました。
>
> 私は当時、「そんな問題起こすようなプログラムは普通書かんよなぁ」
> と思っていたのですが、みごとにやってしまいました。
某 OS では cvsup が引っかかったようです。
# とうちゃん情けなくって涙が出てくらあ (T___________________T
神田敏広 <ca...@kgc.co.jp>