一個毫秒的茶包

UI以日期(僅yyyy/MM/dd)操作 讓後端設定起迄時間的情況, 通常會將迄期設為最後一秒鐘


但一秒鐘的空白其實有點大, 因此在同事的慫恿 敲邊鼓下, 將迄期設為最後一毫秒, 以.999存

於是茶包從天而降!

1. 999 millisecond進DB會被進到下一個毫秒

yyyy/M/d 23:59:59.999 → yyyy/M/d+1 00:00:00.000
如果是做小於的判斷, 其實ok, 若是小於等於, 也就損失一個毫秒, 還能接受, 問題是再拿出來給UI做日期操作時, 就很麻煩處理..

於是得減兩個毫秒, 以.998存, 才能讓.date維持在相同的值

不過又進化為另一個茶包..


2. 998 millisecond進DB會少掉一毫秒

似乎進DB每3個毫秒一組BUS的那種感覺..
yyyy/M/d 23:59:59.998 → yyyy/M/d 23:59:59.997
判斷上差一個毫秒而已, 也是還ok.. 給UI做日期操作 取.date部分不會被改變, 到此迄期做這種處理是無問題的..

麻煩的是, 有個功能是以特定日期前為條件, 這種期限要比照迄期處理; 而一個案件裡, 不能重復設定同一個期限, 需要比較.. 這 就是茶包所在了!
程式的減兩個毫秒 是998 millisecond, 但DB裡會存成997 millisecond, equals是false! 他x的永遠比對不到..
最後減三個毫秒, 以.997存, 真是好不容易..