Java服务端时区的几点思考
2017-06-15 21:29
267 查看
最近半年来开发的几个模块,涉及到了预定,检查,和查询。每个模块相同的都遇到了时间的处理,每次遇到的问题都不太一样。总结一下,避免以后走弯路。
时区概念
时区(Time Zone)是地球上的区域使用同一个时间定义。1884年在华盛顿召开国际经度会议时,为了克服时间上的混乱,规定将全球划分为24个时区。
GMT,UTC,UNIX时间戳
GMT,格林尼治时间。理论上来说,格林尼治标准时间的正午是指当太阳横穿格林尼治子午线时(也就是在格林尼治上空最高点时)的时间。但由于地球在它的椭圆轨道里的运动速度不均匀,这个时刻可能与实际的太阳时有误差,最大误差达16分钟。原因在于地球每天的自转是有些不规则的,而且正在缓慢减速,因此格林尼治时间基于天文观测本身的缺陷,已经不再被作为标准时间使用。
UTC,协调世界时(英:Coordinated Universal Time ,法:Temps Universel Coordonné),又称世界统一时间,世界标准时间,国际协调时间。作为调整,引入了闰秒机制。英文(CUT)和法文(TUC)的缩写不同,作为妥协,简称UTC。UTC与GMT的时间差距不大,但是因为GMT的缺陷,UTC已被作为世界统一的时间标准。
UNIX时间戳,从协调世界时1970年1月1日0时0分0秒起至现在的总秒数,不考虑闰秒 这么做应该是为了简化逻辑。
任何一个绝对的时间点,绝对的时间是一致的,只不过人为地划分了时区以后,我们以一个标准去工作学习,休息。在格林尼治的哥们吃着炸鱼薯条作为午饭抱怨腐国伙食差的时候,身在北京的我们已经看完了新闻联播,而此时的在洛杉矶的老美可能刚刚进入梦乡。
Java内部的时间计算我的理解是在值的计算都以Long型的Unix时间戳计算,但是在转成Date,或者使用DateFormat进行格式化输出为方便人类识别的时候,会结合时区进行转化。
在日常的和日期相关的计算中,常见有将Date转换为固定格式的字符串,或者将一定格式的字符串转换为日期。在这两个过程中,有时会难以思考其中的过程。
其实形如”2017-05-31 22:09:00”这样的字符串时间并没有时区的概念,而Unix时间戳则是某个时刻的绝对时间,也就是某个时刻零时区的绝地时间。
SimpleDateFormat在实例化的时候,会查看是否手动制定了时区,如果有的话使用指定的时区,否则使用系统默认的时区;SimpleDateFormat进行字符串解析的时候,会认为这个时间是内部持有那个时区的时间,然后将这个时区转换为同一时刻的零时区Unix时间戳。
在使用SimpleDateFormat将一个Date时间转为为固定格式的时间时候,实际就是对字符串解析过程的逆过程。
另外在使用Date date = new Date(Long timeStamp)的时候,Date内部也持有了一个TimeZone对象,在使用System.out.println(date)的时候会自动使用内部的时区对象进行字符串的转化。
其实无论怎样转化,只要服务端使用统一的标准,可以减少不同时区之间的转换和思考过程,更不易产生错误。
客户端的时间是不可信的,一定要使用服务端时间。
服务端的时间在进行国际化的时候,需要考虑时区对业务的影响。
时区除了影响时间值的计算外,对某些字符串信息的格式化也有重要影响。
时区概念
时区(Time Zone)是地球上的区域使用同一个时间定义。1884年在华盛顿召开国际经度会议时,为了克服时间上的混乱,规定将全球划分为24个时区。
GMT,UTC,UNIX时间戳
GMT,格林尼治时间。理论上来说,格林尼治标准时间的正午是指当太阳横穿格林尼治子午线时(也就是在格林尼治上空最高点时)的时间。但由于地球在它的椭圆轨道里的运动速度不均匀,这个时刻可能与实际的太阳时有误差,最大误差达16分钟。原因在于地球每天的自转是有些不规则的,而且正在缓慢减速,因此格林尼治时间基于天文观测本身的缺陷,已经不再被作为标准时间使用。
UTC,协调世界时(英:Coordinated Universal Time ,法:Temps Universel Coordonné),又称世界统一时间,世界标准时间,国际协调时间。作为调整,引入了闰秒机制。英文(CUT)和法文(TUC)的缩写不同,作为妥协,简称UTC。UTC与GMT的时间差距不大,但是因为GMT的缺陷,UTC已被作为世界统一的时间标准。
UNIX时间戳,从协调世界时1970年1月1日0时0分0秒起至现在的总秒数,不考虑闰秒 这么做应该是为了简化逻辑。
任何一个绝对的时间点,绝对的时间是一致的,只不过人为地划分了时区以后,我们以一个标准去工作学习,休息。在格林尼治的哥们吃着炸鱼薯条作为午饭抱怨腐国伙食差的时候,身在北京的我们已经看完了新闻联播,而此时的在洛杉矶的老美可能刚刚进入梦乡。
Java内部的时间计算我的理解是在值的计算都以Long型的Unix时间戳计算,但是在转成Date,或者使用DateFormat进行格式化输出为方便人类识别的时候,会结合时区进行转化。
在日常的和日期相关的计算中,常见有将Date转换为固定格式的字符串,或者将一定格式的字符串转换为日期。在这两个过程中,有时会难以思考其中的过程。
其实形如”2017-05-31 22:09:00”这样的字符串时间并没有时区的概念,而Unix时间戳则是某个时刻的绝对时间,也就是某个时刻零时区的绝地时间。
SimpleDateFormat在实例化的时候,会查看是否手动制定了时区,如果有的话使用指定的时区,否则使用系统默认的时区;SimpleDateFormat进行字符串解析的时候,会认为这个时间是内部持有那个时区的时间,然后将这个时区转换为同一时刻的零时区Unix时间戳。
在使用SimpleDateFormat将一个Date时间转为为固定格式的时间时候,实际就是对字符串解析过程的逆过程。
另外在使用Date date = new Date(Long timeStamp)的时候,Date内部也持有了一个TimeZone对象,在使用System.out.println(date)的时候会自动使用内部的时区对象进行字符串的转化。
其实无论怎样转化,只要服务端使用统一的标准,可以减少不同时区之间的转换和思考过程,更不易产生错误。
客户端的时间是不可信的,一定要使用服务端时间。
服务端的时间在进行国际化的时候,需要考虑时区对业务的影响。
时区除了影响时间值的计算外,对某些字符串信息的格式化也有重要影响。
相关文章推荐
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- Java中异常机制的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 关于利用JAVA开发游戏外挂的几点思考
- 从C++到Java,10年技术生涯的几点思考 转
- 从C++到Java语言的10年技术生涯的几点思考
- 关于Java框架Vert.x的几点思考
- [转]从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 转载:从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 从C++到Java,10年技术生涯的几点思考
- 关于Java中的HashMap的深浅拷贝的测试与几点思考
- 从C++到Java,10年技术生涯的几点思考