Oracle SQL日期过长，反之亦然

Oracle SQL日期过长，反之亦然

您在转换中失去了太多的精度，无法以其他方式返回。您可以通过使用时间戳而不是日期来获得更近的距离。

首先，您的初始查询完全失去了时间部分：

select to_char(date '1970-01-01'  + (1432550197431912935 - power(2, 60))/power(2, 44), 'YYYY-MM-DD HH24:MI:SS')from dual;2013-07-09 01:13:19

…但是即使这样，转换回来也已经失去了太多：

select ((to_date('2013-07-09 01:13:19','YYYY-MM-DD HH24:MI:SS')  - date '1970-01-01') * power(2, 44)) + power(2, 60) from dual;1432550197477589405

它比您获得的1432549301782839296更近，但还有很长的路要走。

问题的一部分是的精度

DATE

，仅次于秒。如果使用，

TIMESTAMP

则可以很接近。您会发现所拥有的价值据称非常精确：

select timestamp '1970-01-01 00:00:00'  + numtodsinterval((1432550197431912935 - power(2, 60))/power(2, 44), 'DAY')from dual;2013-07-09 01:13:18.775670462

时间戳算法会给出间隔结果，因此将其转换回原值变得很复杂，然后您必须 *** 纵该结果才能返回数字，首先要返回原始天数：

select extract(day from int_val)  + extract(hour from int_val) / 24  + extract(minute from int_val) / (24 * 60)  + extract(second from int_val) / (24 * 60 * 60)from (select to_timestamp('2013-07-09 01.13.18.775670462', 'YYYY-MM-DD HH24:MI:SS.FF9')  - timestamp '1970-01-01 00:00:00' as int_val from dual);15895.0509117554451620370370370370370371

…然后通过您的力量 *** 纵：

select ((extract(day from int_val)    + extract(hour from int_val) / 24    + extract(minute from int_val) / (24 * 60)    + extract(second from int_val) / (24 * 60 * 60))  * power(2, 44)) + power(2, 60)as xfrom (select to_timestamp('2013-07-09 01.13.18.775670462', 'YYYY-MM-DD HH24:MI:SS.FF9')  - timestamp '1970-01-01 00:00:00' as int_val from dual);1432550197431912935.09988554676148148148

这真是太贴心了。您可以将其截断或四舍五入到最接近的整数。

---

仅查看您的数字和每种方式的幂运算，就表明它似乎在Oracle可以应对的精度范围内：

select (1432550197431912935 - power(2, 60)) / power(2, 44)from dual;15895.050911755445156359201064333319664select (15895.050911755445156359201064333319664 * power(2, 44)) + power(2, 60)from dual;1432550197431912935.000...

即使带有时间戳，您也会丢失一些，因为该第一个值超过了9位数的小数秒限制。代表小数秒的部分（一旦计算了15895小时等）是

.0000089776673785814232865555418862

一天，即

.77567046150943497195839881896768

秒；时间戳将其四舍五入

.775670462

。因此，它永远不会是完美的。

这也使人们想知道原始数字是如何产生的。由于它低于yoctoseconds，因此实际上似乎不太可能代表该时间达到极高的精度。尚不清楚“精度”是否实际上是基于2的幂进行 *** 纵的伪像，但无论如何它看起来并不是很有用。如果必须将其存储为数字，则使用Unix风格的纪元日期更为常见，该纪元自您正在使用的纪元日期起算是几秒或几毫秒。这个设计很有趣。