共计 2237 个字符,预计需要花费 6 分钟才能阅读完成。
Choice, is to save time.
Unix time
协调世界时(UTC)是世界上调节时钟和工夫的次要工夫规范,它与 0 度经线的平太阳时相差不超过 1 秒,并不恪守夏令时。
Unix time,或称 POSIX 工夫是 UNIX 或类 UNIX 零碎应用的工夫示意形式: 从 UTC1970 年 1 月 1 日 0 时 0 分 0 秒起至当初的总秒数,不思考闰秒 ,有些零碎应用 32 位整数存储,会有 2038 年问题。
Unix time 就是 UTC+0 工夫的工夫戳
Y2038
2038 年问题是指在应用 POSIX 工夫的 32 位计算机应用程序上,格林尼治工夫 2038 年 1 月 19 日凌晨 03:14:07(北京工夫:2038 年 1 月 19 日中午 11:14:07)之后无奈失常工作
Java
public static void main(String[] args) {System.out.println("Y2038:" + Instant.ofEpochSecond(2147483647L));
System.out.println("Java max date:" + Instant.ofEpochMilli(Long.MAX_VALUE));
System.out.println("Java max date:" + new Date(Long.MAX_VALUE));
}
Y2038 问题:2038-01-19T03:14:07Z
Java 最大工夫:+292278994-08-17T07:12:55.807Z
Java 最大工夫:Sun Aug 17 15:12:55 CST 292278994 ## 时区问题造成不同
Java 没有 Y2038 问题,即便是应用 Date
也没有
JavaScript
let maxDateNowValue = 8640000000000000;
console.log("js max date:" + new Date(maxDateNowValue).toISOString());
// Max value plus 1 millisecond
let plusOneMS = maxDateNowValue + 1;
console.log(new Date(plusOneMS).toString()); // Invalid Date
js max date: +275760-09-13T00:00:00.000Z
Invalid Date
JavaScript 也没有 Y2038 问题,但能示意的最大工夫比 Java 小
JavaScript 最大工夫根据 https://stackoverflow.com/que…
工夫格局
public static void main(String[] args) {Instant now = Instant.now();
System.out.println("Z :"+now.atZone(ZoneId.of("Z")));
System.out.println("UTC+0 :"+now.atZone(ZoneId.of("UTC+0")));
System.out.println("UTC+8 :"+now.atZone(ZoneId.of("UTC+8")));
System.out.println("GMT :"+now.atZone(ZoneId.of("GMT")));
System.out.println("GMT+8 :"+now.atZone(ZoneId.of("GMT+8")));
System.out.println("Asia/Shanghai :"+now.atZone(ZoneId.of("Asia/Shanghai")));
}
Z : 2022-06-18T08:35:46.326Z
UTC+0 : 2022-06-18T08:35:46.326Z[UTC]
UTC+8 : 2022-06-18T16:35:46.326+08:00[UTC+08:00]
GMT : 2022-06-18T08:35:46.326Z[GMT]
GMT+8 : 2022-06-18T16:35:46.326+08:00[GMT+08:00]
Asia/Shanghai : 2022-06-18T16:35:46.326+08:00[Asia/Shanghai]
下面是同一个工夫的不同格局,T
用于分隔日期和事件,Z
和 +08:00
都是示意基于规范工夫的偏移量,Z = UTC+0
\ +08:00 = UTC+08:00
,[UTC+08:00]
示意采纳的规范和偏移量
协调世界时(UTC)是最靠近格林威治规范工夫(GMT)的几个代替工夫零碎之一。对于大多数用处来说,UTC 工夫被认为能与 GMT 工夫调换,但 GMT 工夫已不再被科学界所确定
理论应用中 GMT 也能够配合偏移量应用,能够了解为和 UTC 是雷同的
UTC 相当于是按经度划分的时区,Asia/Shanghai 是按行政区域划分的时区
时区问题
时区问题的实质是,不同的服务运行在不同时区的服务器上,在互相传输工夫数据时,没有正确的解决时区,可能是在发送数据时,也可能是在接收数据时,或者两种状况都有。
如下的数据,不同时区的服务都会认为是当地时区的工夫,无从通晓原始数据的时区:
{
"message": "hello world",
"createTime": "2022-06-01 12:00:00"
}
在工夫表达式中退出时区信息能够防止这样的误会
{
"message": "hello world",
"createTime": "2022-06-01T12:00:00Z"
}
更多时区问题请移步:Web 开发中的时区问题