数据库里时间的存储，你更偏向于哪种方式？

[Inhibitory]

1. 使用Timestamp，则会在数据库里存储：2013-07-16 07:20:01。
在不同时区，显示的都是2013-07-16 07:20:01，但其实他们并不是同一时间了。

2. 存储事件发生的时间毫秒值，在不同时区解析出来的时间表示不一样，但表达都是同一时间，能解决时区问题。

我个人偏向于存储时间的毫秒值，但是在很多地方看到却都是存储Timestamp，讲数据库的视频里也大多是用Date，Timestamp。
当我们的程序有多国用户时，解决时区问题是必要的。

你更喜欢哪一种方式呢？

[Inhibitory]

1. 2013-07-16 07:20:01: 一眼看出时间，在程序里直接就是Date或者Timestamp了。 2. 时间的毫秒值：一眼看不出时间，显示时需要相应的转换成Date或者Timestamp再使用。

[oh_Maxy]

我们用的是字符串存储，比较土。。

[菖蒲老先生]

一般用第一种吧，比较直观，若是含有多国用户取出来的时候用TimeZone转一下好了。。。 当然还得具体情况具体分析，反正暂时还没碰到存ms的。。。

[想喝咖啡的貓]

long ,原因加减算法简单。

[Inhibitory]

引用 3 楼 flagiris 的回复:

一般用第一种吧，比较直观，若是含有多国用户取出来的时候用TimeZone转一下好了。。。 当然还得具体情况具体分析，反正暂时还没碰到存ms的。。。

TimeZone转的话是可以，但是需要知道保存的TimeZone是哪一个TimeZone，这样需要存储原始的TimeZone

[rencht]

第一种比较直观； 要是第二种做测试的到数据库看数据肯定要疯掉= =

[loveofmylife]

直接存date，有时候你需要对某一天进行分组统计，如果你存的是毫秒就不好操作了，时区的问题除非你的产品是外网项目，不然基本上都是在一个时区里使用的

[loveofmylife]

可以参考jira,公司内部不同地区的部门公用一套jira，会出现时区问题，但是jira里会有一个设置时区的地方，你显示的时间都是以这个时区为标准

[Inhibitory]

引用 7 楼 viszl 的回复:

直接存date，有时候你需要对某一天进行分组统计，如果你存的是毫秒就不好操作了，时区的问题除非你的产品是外网项目，不然基本上都是在一个时区里使用的

这个是需要考虑的。

[Inhibitory]

引用 8 楼 viszl 的回复:

可以参考jira,公司内部不同地区的部门公用一套jira，会出现时区问题，但是jira里会有一个设置时区的地方，你显示的时间都是以这个时区为标准

美国用户显示中国时间，你觉得客户会同意吗？

[风中的木头]

引用 7 楼 viszl 的回复:

直接存date，有时候你需要对某一天进行分组统计，如果你存的是毫秒就不好操作了，时区的问题除非你的产品是外网项目，不然基本上都是在一个时区里使用的

比较赞同这个观点，后续作分析的话面对ms存储会崩溃的

[风中的木头]

引用 10 楼 Inhibitory 的回复:

[quote=引用 8 楼 viszl 的回复:] 可以参考jira,公司内部不同地区的部门公用一套jira，会出现时区问题，但是jira里会有一个设置时区的地方，你显示的时间都是以这个时区为标准

美国用户显示中国时间，你觉得客户会同意吗？[/quote] 存储统一用一个时区，至于显示，完全可以通过在视图层通过判断IP地址等手段作一次针对时区的转换吧

[风_晓寒]

存时间格式吧，根据时区的不同对数据处理下咯，看毫秒值会死掉了。。

[suciver]

第一种比较直观,维护和比对起来也方便。至于多国用户了必然涉及国际化了，一般涉及国际化的网站都有让用户选择自己的国家语言根据他们选择的相应国语我们在转换相应的时区。

[zuxianghuang]

我一般用datetime

[花谢尊前不敢香]

用的是@Temporal(TemporalType.TIMESTAMP)的路过。 这要看数据库是否支持对应的类型了。

[T0M]

引用 14 楼 suciver 的回复:

第一种比较直观,维护和比对起来也方便。至于多国用户了必然涉及国际化了，一般涉及国际化的网站都有让用户选择自己的国家语言根据他们选择的相应国语我们在转换相应的时区。

都选英语你就哭吧，好多国家。我们是按照货币代码分时区和做汇率结算。