0.9.6.5-RC3で紀元前データの扱いを実装していたところ、
https://www.seasar.org/issues/browse/DBFLUTE-644
妙な現象に遭遇しました。
発生環境:
Oracle 10g XE
ojdbc5.jar / ojdbc6.jar (両方とも)
紀元前日付を登録してその後検索すると、
年が一つ古い日付が帰って来ます。
登録:紀元前1234/01/01 12:34:56
検索:紀元前1235/01/01 12:34:56
登録前のプログラム上で生成したDate型のmillisecondと
検索で取得したDate型のmillisecondが明らかに違うもの
になっています(ぴったり一年分だけ違う)。
これは、DATE型でもTimestamp型でも両方で発生しました。
他の紀元前をサポートするDB(PostgreSQL, H2)では、
この現象は発生しません。
もし、"Oracle 11g" の環境のある方、
試しに紀元前日付を試して頂けないでしょうか?
(DBFlute経由でも別経由でもなんでもOK)
final Calendar cal = Calendar.getInstance();
cal.clear();
cal.set(1, 0, 1, 0, 0, 0);
cal.set(Calendar.MILLISECOND, 0);
long beforeMillis = cal.getTimeInMillis() - 1L
... = new Timestamp(beforeMillis);
で、紀元前の日付は作成できます。
(紀元前最後のミリ秒になります)
もし、dbflute-oracle-exampleをOracle11gで動く環境で
構築されている場合は、VendorPlainTestの
テストケースをすぐに動かすことで確認できます。
#
# そんな急ぎのものじゃないので、
# 気の向いたときにという感じで。
# 結果がどうあれ、どうしようもないっちゃ
# どうしようもないので...
#
11g(11.1.0.6.0)で試してみました。
「テストケースが通ったー」と思ったら、「年があわないのが正しい動作」にしているのですね・・・
確かにぴったり1年分多い(?)状態になっています。
"select to_char(birthdate, 'syyyy-mm-dd') from member"
だと、正しい日付文字列が戻ってきましたので、JDBCが腐ってそうな気がします。
おお、hajimeniさん、ありがとう!
そう、「年があわないのが正しい動作」に
してます。(Oracleの仕様はこうだ!って感じで)
> "select to_char(birthdate, 'syyyy-mm-dd') from member"
ふへー、そうなんだね。やはりJDBCかな。
まあ、Oracleでこうなんだから、紀元前のデータを
正確な日時として取り扱うような要件はほとんど
ないってところかな、恐らく。
(そもそも、Oracleはよく日付型利用せずにchar(8)日付
とか利用されることが多かったし)
ありがとう。なんか、DBFluteでフィルタ掛けるのも
違う感じなので(JDBCが直ったら逆におかしくなっちゃう)、
とりあえずは "こうなる" ってことがわかっただけでOKです。
2010/2/16 hajimeni <hajim...@gmail.com>:
> --
> このメールは Google グループのグループ「DBFluteユーザの集い」の登録者に送られています。
> このグループに投稿するには、dbf...@googlegroups.com にメールを送信してください。
> このグループから退会するには、dbflute+u...@googlegroups.com にメールを送信してください。
> 詳細については、http://groups.google.com/group/dbflute?hl=ja からこのグループにアクセスしてください。
>
>