世界时区和Java时区详解
2021-06-22 02:03
标签:分享 问题 timezone 研究 EDA 程序 详细 sha ring Druid中时区的问题一直困扰着我们,所以我专门去研究了一下世界时区和Java中的时区,对使用Druid很用帮助. UTC时间是时间标准时间(Universal Time Coordinated),UTC是根据原子钟来计算时间,误差非常小。 UTC也是指零时区的时间,如果要表示其他时区的时间,这里要注意没有UTC+0800或者UTC+8这样的表示方式(至少Java里面没有,一般用于口头表示),只有Asia/Shanghai这样的表示方式,详细的时区列表参考这个文档时区列表?,不要问我为什么没有北京时区。。。 GMT时间是根据地球的自转和公转来计算时间,老的时间计量标准,这里我们不过多讨论 我们一般表示时间都会带格式以方便理解,例如时间表达式是‘2018-09-12 08:00:00‘,因为我们在东八区,所以默认是:北京时间2018年9月12号8点整。但是如果是一个美国人看到这个时间,就会认为是美国东部or西部时间的2018年9月12号8点整。所以从这种表达方式很不准确,因为没有指明到底是哪个时区的时间!!!! 所以准确的表达时间必须带有时区,例如2018-09-12 08:00:00+0800,表达了Asia/Shanghai这个时区的时间2018年9月12号8点整。这里要注意+0800并不是表示加8小时的意思,只是表示这个时间‘2018-09-12 08:00:00‘是东八区Asia/Shanghai的时间,仅此而已。 讲清楚了时间表达方式,再讲时间戳。其实时间戳是没有时区概念的,或者说时间戳只能是0时区的。时间戳是从1970-01-11 00:00:00+0000开始的(原因大家都知道),也就是在‘1970-01-11 00:00:00+0000‘这个时间点,时间戳是0。再换句话说在‘1970-01-11 08:00:00+0800‘时间戳也是0。这也是Java里时间组件的默认方式,不管用户输入的人类可识别的时间是什么格式,在内部统一存的是时间戳。 例如时间是‘2018-09-01 08:00:00+0800‘,那么使用date.getTime()获取到时间戳是1535760000000;时间是‘2018-09-01 00:00:00+0000‘,获取到时间戳也是1535760000000。 测试代码如下: 可以观察到这2行代码的输出都是1535760000000,这就证明了上面的观点。再啰嗦2点: 第一行代码DateFormat中Z表示时区,所以String类型格式时间带上+0800这种表达式,就能正确获取时间戳了。 SimpleDateFormat是线程不安全的,不要用 为什么我们写以下代码的时候,程序能正确知道我们的时区呢? 因为我们在mac上设置了时区 在Java中也可以设置时区 1)启动设置 2) 代码中设置 3) 单次处理生效,建议使用joda的时间包 世界时区和Java时区详解 标签:分享 问题 timezone 研究 EDA 程序 详细 sha ring 原文地址:https://www.cnblogs.com/oldtrafford/p/9680791.html0、引言
1、UTC时间&GMT时间
2、表达时间方式
3、UTC时间的时间戳
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ssZ");
System.out.println(sdf.parse("2018-09-01 08:00:00+0800").getTime());
System.out.println(sdf.parse("2018-09-01 00:00:00+0000").getTime());
4、时区设置
SimpleDateFormat sdf2 = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
System.out.println(sdf2.parse("2018-09-01 08:00:00").getTime());
java -Duser.timezone=Asia/Shanghai -jar xxx.jarTimeZone.setDefault(TimeZone.getTimeZone("UTC"));
SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");
System.out.println(sdf.parse("2018-09-01 08:00:00").getTime());