这是一个创建于 488 天前的主题，其中的信息可能已经有所发展或是发生改变。
ES 官网说，
- 超过纪元（ 1970 ）以前的日期无法使用整型表示，要用日期格式的字符串
- 可又说，内部日期都会转为整型，表示 milliseconds-since-the-epoch ==》 那这种情况，若 1970 之前的日期呢？难道是区别对待吗？分两种情况存储吗？（ 1 ） 1970 后的日期，不管啥格式都内部转整型存储 （ 2 ） 1970 前的时间，就用字符串存储
若有大佬知晓，还请不吝解释。
以下为官网原话：
- Values for milliseconds-since-the-epoch must be non-negative. Use a formatted date to represent dates before 1970.
- Internally, dates are converted to UTC (if the time-zone is specified) and stored as a long number representing milliseconds-since-the-epoch.
- Queries on dates are internally converted to range queries on this long representation, and the result of aggregations and stored fields is converted back to a string depending on the date format that is associated with the field.
- Dates will always be rendered as strings, even if they were initially supplied as a long in the JSON document.
 |
1
julyclyde 2022-12-15 10:30:50 +08:00
和 1970 相关很有可能是 unix timestamp 吧
|
 |
2
lllpla 2022-12-15 10:47:19 +08:00
说的挺清楚吧 1970 年开始的毫秒值。
1970 年 1 月 1 日 0 时 0 分 0 秒是 0 ，再之前的无法表示。 |
 |
3
yangyaofei 2022-12-15 11:47:36 +08:00
这个貌似并不是他真的底层实现, 这个只是他的 Mapping 方式.
我曾经试验过, 存入的字符串是一直存储的, 不管是够改动了 Mapping 什么的都不会变, 但是解析的结果可能会有不一样或者不能解析. 可能他内部直接使用的 Lucene 的时间存储, 至于是什么其实不太重要吧, 可以翻源码 |
 |
4
deadlyn OP @lllpla 是的，官方说的是，内部会将日期转 UTC 并以长整型存储（ milliseconds-since-the-epoch ），疑问是：内部转换以时间戳存储，而这个时间戳只能表示 1970 后的日期，那 1970 前的日期内部如何处理存储呢？
Internally, dates are converted to UTC (if the time-zone is specified) and stored as a long number representing milliseconds-since-the-epoch. |
|
5
deadlyn OP @yangyaofei 嗯，就是读到了官方 doc ，感觉有点冲突，没太理解，有点好奇而已
|
Select Language