关于java:Web-开发中的时间问题

Choice, is to save time.

协调世界时（UTC）是世界上调节时钟和工夫的次要工夫规范，它与 0 度经线的平太阳时相差不超过 1 秒，并不恪守夏令时。

Unix time，或称 POSIX 工夫是 UNIX 或类 UNIX 零碎应用的工夫示意形式： 从 UTC1970 年 1 月 1 日 0 时 0 分 0 秒起至当初的总秒数，不思考闰秒 ，有些零碎应用 32 位整数存储，会有 2038 年问题。

Unix time 就是 UTC+0 工夫的工夫戳

2038 年问题是指在应用 POSIX 工夫的 32 位计算机应用程序上，格林尼治工夫 2038 年 1 月 19 日凌晨 03:14:07（北京工夫：2038 年 1 月 19 日中午 11:14:07）之后无奈失常工作

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 也没有

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 开发中的时区问题

Unix time

Y2038

Java

JavaScript

工夫格局

时区问题