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:07ZJava 最大工夫：+292278994-08-17T07:12:55.807ZJava 最大工夫：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 millisecondlet plusOneMS = maxDateNowValue + 1;console.log(new Date(plusOneMS).toString()); // Invalid Date
js max date: +275760-09-13T00:00:00.000ZInvalid 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.326ZUTC+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开发中的时区问题