SQL日期時間格式給出不同的結果

我跑的查詢中，我想找到所有作了開始6月1日的訂單本來我用這個代碼：SQL日期時間格式給出不同的結果

select blah blah 
Where ORDERS.ORDER_DATE > '2016-05-31 23:59:59.999'

但查詢失敗以選擇6月1日訂單。當我更改代碼：

Where ORDERS.ORDER_DATE > '2016-05-31 23:59:59.99'

我得到了6月1日的訂單。差別在於末尾的_2_ nines (.99)與_3_ nines (.999）在幾秒鐘內。數據總是在分數中顯示3個數字。（我們的數據只顯示零秒的分數"XX:XX:XX.000"）

這是怎麼回事？

來源

2016-07-22 StandardAsker

我試圖構建日期範圍時，目睹了精度問題，所以我選擇了簡化它。我敢肯定，你已經考慮過這個

Select ... ORDERS.ORDER_DATE >= '2016-06-01'

來源

2016-07-22 23:37:52

的SQL服務器，任何超過0.997毫秒圍捕所以「2016-05-31 23:59:59.999」被評爲同爲「2016-06-01 00:00:00.000」。再加上你的數據可能更多的是DATE，結果你不會得到2016-06-01。

因爲

select blah blah 
Where ORDERS.ORDER_DATE > '2016-05-31 23:59:59.999'

會爲

select blah blah 
Where ORDERS.ORDER_DATE > '2016-06-01 00:00:00.000'

進行評價，如果您的日期不大於6/1，你就不會得到結果

爲什麼0.99作品bacuase

select blah blah 
Where ORDERS.ORDER_DATE > '2016-05-31 23:59:59.99'

評價爲

select blah blah 
Where ORDERS.ORDER_DATE > '2016-05-31 23:59:59.990'

來源

2016-07-22 23:39:12 Matt

賠率是一對一的，但只有>會在午夜時忽略任何交易。這就是說，感謝3毫秒的項目。這正是我改變我的方法之前所見證的。 –

是在午夜時分，但是想想看，當您使用這樣的DATETIME過濾器時，如果真的將其應用於僅僅是DATE的列，這意味着所有事情都是午夜，那麼您實際上在6/1上排除了每個結果，而不是午夜。這是不使用BETWEEN並在一側使用> =（或<=）並且僅在另一側使用>或<的另一個主要原因。 – Matt

3ms舍入不完全正確：「datetime值將四捨五入爲.000，.003或.007秒的增量，如下表所示。「 https://msdn.microsoft.com/en-us/library/ms187819.aspx實際上，10中的4取整爲.XX7。這不適用於'datetime2'。 – shawnt00

你不能假設精度。當日期字符串轉換爲日期時間時，它最終會變成'2016-06-01'。我猜你的訂單沒有時間分量，所以他們也有'2016-06-01'，因爲你正在做>你錯過了它們。 datetime docs顯示的時間範圍是00:00:00 through 23:59:59.997。試試這個看：

CREATE TABLE test_date (dt datetime); 
insert into test_date values ('2016-05-31 23:59:59.999') 
select * from test_date 
-- result: 'June, 01 2016 00:00:00'

做到這一點是使用你想要確切的開始時間，只使用>=，並使用<的結束日期與確切的開始時間以及今後一個時期的正確方法。

select blah blah 
Where ORDERS.ORDER_DATE >= '2016-06-01'

這會工作，不管你用什麼日期類型用於存儲ORDER_DATE，如果您移動數據庫到另一個系統可能有一個DateTime對象的時間部分不同的精度。

來源

2016-07-23 01:46:05

SQL日期時間格式給出不同的結果

回答

相關問題