- 主题:时间是存string好?还是datetime?还是timestamp好？时区怎么办？
re
一般情况下时区应该是个前端概念
应该和i8n之类统一考虑
【 在 guestking (无) 的大作中提到: 】
: 对后端来说，long就没有时区问题了
: 让前端自己去决定用什么时区
--
FROM 218.79.251.*
以前遇到这种一般都是直接冗余分组字段
反正时间戳这种东西都是一次写入没有update
【 在 guestking (无) 的大作中提到: 】
: 就有一类的情况用long不好
: 比如要按天聚合数据
: 这种情况是vchar存日期比较快还是用Date比较快?
: ...................
--
FROM 218.79.251.*
有独立api
System.nanoTime()
然后有一套新加的localtime可以处理纳秒
【 在 here080 (hero080) 的大作中提到: 】
: 这么差劲的吗？就没有JVM能实现更高精度的？
--
修改:oldwatch FROM 218.79.251.*
FROM 218.79.251.*
需要按天汇总的东西，一般不会跟着updatetime走吧
否则可能会触发溯及既往的更新，很恶心的
【 在 guestking (无) 的大作中提到: 】
: 你不用updatetime的吗
--
修改:oldwatch FROM 218.79.251.*
FROM 218.79.251.*
新日期库出来之前，java时间类只有date和calendar
timestamp是从date继承的
【 在 here080 (hero080) 的大作中提到: 】
: Timestamp类本身就有纳秒接口啊，没道理它里面不存啊。
--
FROM 218.79.251.*
sql.timestamp
多半就是默认只和sql 的timestamp对接
保证能保精度读写数据库的对应字段
和system的date保精度转换就成了另一个层面的问题了
【 在 here080 (hero080) 的大作中提到: 】
: 那所以它自己是存的，只是当成date时没有？
--
FROM 218.79.251.*
所以sql timestamp带了nano 字段么
保证能从db读写到纳秒精度
但是date对纳秒的支持因为牵涉到向后兼容问题
就只能另开新工具类了
带纳秒和不带纳秒的date对象的比较没法处理
【 在 here080 (hero080) 的大作中提到: 】
: sql有很多啊，不少都支持高于毫秒的精度吧。
: 比方说PostgreSQL 就支持到微秒。
--
FROM 218.79.251.*
进存储不一律转换成UTC么？
难道还存时区？
【 在 AutumnNight (秋夜) 的大作中提到: 】
: 看需求，如果时间只是展示用，写一次完事，那string
: 如果要在数据库里进行时间加减运算，那就数据库内置类型
: 如果是跨国应用，考虑时区
: ...................
--
FROM 114.92.202.*
嗯
我现在反正能存/传long一律走long
反正还没见过不能处理UTC的环境
【 在 guestking (无) 的大作中提到: 】
: 综合来看，还是存long最方便
: 除了不能聚合之外，基本没太大的缺点
--
FROM 114.92.202.*