実際、ドキュメントの1行に関する投稿が判明しました。 しかし、これは予想外だったので、見つけたものをあなたと共有することにしました。
新しいデザイナーである新しいテーブルは、それらのテストを提出することを決定し、一般的に、私が書いた最初のテストがデータベースに投げたオブジェクトがデータベースから削除された同じオブジェクトと等しくないという事実に違反したときに驚いた。
繰り返し起動した後、ミリ秒が収束しなかったことが明らかになりました。 さて、つまり、あなたはそのようなオブジェクトを取り、「ここに新しい日付（）があり、それをデータベースに書き込む」と言います。 今IDで読んでください。 そして今、等しい。 一体何？ O_o。」 そのようなもの。 そして、はい、テストが突然成功する可能性があります。
掘り下げた後、興味深いことが判明しました。
Sybase Webサイトのドキュメントには、使用されているデータ型の説明が含まれています。 日時データ型の場合、ASEバージョン15.0にはこれのみがありました。
リンクが壊れている場合、Adaptive Server Enterprise 15.0>リファレンスマニュアル：ビルディングブロック>システムおよびユーザー定義のデータ型>日付と時刻のデータ型
datetime列は、1753年1月1日から9999年12月31日までの日付を保持します。datetime値は、このレベルの粒度をサポートするプラットフォームで1/300秒まで正確です。 ストレージサイズは8バイトです。1900年1月1日の基準日からの日数は4バイト、時刻は4バイトです。もう一度、私は次の事実に注意を引く
日時値は1/300秒まで正確です日は上位4バイトで、時刻は下位4バイトで保存されます。 日、24時間* 60分* 60秒* 1000ミリ秒= 86_400_000ミリ秒（日）、4バイト（0x5_26_5C_00）に完全に適合する数値。 サインビットでも場所があります。 誰か、時刻が合わないように時刻を保存する方法を教えてください。
ASE 15.7では、このデータ型の動作の説明が若干拡張されています。
Adaptive Server Enterprise 15.7>リファレンスマニュアル：ビルディングブロック>システムおよびユーザー定義のデータ型>日付と時刻のデータ型
datetime列は、1753年1月1日から9999年12月31日までの日付を保持します。datetime値は、このレベルの粒度をサポートするプラットフォームで1/300秒まで正確です。 小数秒の最後の桁は常に0、3、または6です。他の桁はこれら3桁のいずれかに丸められるため、0と1は0に丸められます。 2、3、および4は3に丸めます。 5、6、7、および8は6に丸められます。 9を10に丸めます。ストレージサイズは8バイトです。1900年1月1日の基準日からの日数は4バイト、時刻は4バイトです。つまり、1つのタイムスタンプでオブジェクトを記録し、「ほぼ同じ、場合によってはまったく同じ」と読みます。 9が外れた場合、少し先に進むこともできます（ミリ秒）。
まあ、これは文書化されているので、これはバグではなく機能であり、Sybaseに対する苦情はありません。
そのすべてについて、ASE 15.7には
bigdatetime列には、0001年1月1日から9999年12月31日までと12：00：00.000000 AMから11：59：59.999999 PMまでの日付が保持されます。 そのストレージサイズは8バイトです。 bigdatetimeの内部表現は、 0000年1月1日以降のマイクロ秒数を含む64ビット整数です。
この投稿の教訓：RTFMとbigdatetimeを使用、ルーク！