2002-01-29 [長年日記]
λ. 情報通信セキュリティ論のテストもダメげ。特にOECD関係の問題が一問も解答出来なかったのが痛い。でもまー、終わったものはどうにも出来ないし。
λ. 開き直って、Amayaの方を何とかしなきゃ。Amayaの国際化にはそうそうたる人々が沢山挫折しているそうなので、俺みたいなヘナチョコがその壮大なリストの末尾に名を連ねたところで、驚くことではないのだけど……それにしたって言い訳出来るくらいの成果は出さないと、何かとナニなわけでございまして……
λ. 閏秒対策!?
@date+24*60*60として翌日を求めている部分があるけど、閏秒を考えるともう一秒進めておいた方が良さそうな気がする。どうでしょう? > たださん
参考 → プログラミングと暦
λ. Groundless Optimism Considered Harmful
根拠なく楽観的であるのは有害だと思う今日このごろ。
λ. テクハラ
毎日新聞の夕刊に落合恵子による「テクスチュアル・ハラスメント - 女性の表現を抹殺するもの」というコラムがあった。当然、例の裁判の事も言及されているんだけど、なんかなぁ。とりあえずメモ。
λ. Quine's NF, NF
なるほど。
λ. MSVC style bit packing
なるほど。-fnative-struct を使うと具体的にはそう変化するのか。
ということは、これはRuby側がbit fieldを使ってないから問題ないということなのかな。
おお、ふなばさんのページかぁ。<br>単純に1秒多く加算すると、偶然うるう秒の日の23:59:60に実行されたときには助かる一方で、00:00:00に実行されると2日先になってしまうような気がするけど……。
翌日を求める際の基準になるのは、TDiaryAdmin#initializeで @date = Time::local( @cgi['year'][0].to_i, @cgi['month'][0].to_i, @cgi['day'][0].to_i ) として作られているTimeオブジェクトだと思うので、時刻の基準としては00:00:00だけ考えれば良い気がします。<br><br>で、この00:00:00から24*60*60+1秒進めた場合、<br>閏秒で1秒多い日だと翌日00:00:00<br>普通の日だと翌日00:00:01<br>となって、具合いが良いのではないかと。<br><br># あぁ。何か勘違いしてそうで怖い…… (^^;;
あぁ、そうか。おっしゃる通り。将来の互換性にやや不安があるけど(笑)。<br>つーことは、「前日」はたかだか1秒引けばいいだけか……。