UNIX时间是否通用
Is UNIX time universal
我在网上做了一些调查，但仍然很困惑。 UNIX 时间是像 GMT/UTC 一样的通用时间还是像当地时间一样因地而异？
我知道 UNIX 时间是从 1970 年 1 月 1 日开始计算的 00:00:00 GMT。当我在 Java 中使用 getTime() 函数时（更具体地说 Date d= new Date(); long currentTime d.getTime()），我得到了以毫秒为单位的 UNIX 时间。现在如果A和B在两个不同的时区使用相同的功能，他们会得到相同的结果吗？
Now If person A and person B use the same function who are sitting in two different time zones, will they get the same result?
是的，他们会的 - 当然假设他们的时钟都是 "correct"。
java.util.Date class 基本上是 "the time since the Unix epoch, in milliseconds" 的包装。考虑到 Unix 纪元是 瞬间 时间（不仅仅是 "midnight on January 1st 1970"，无论你身在何处，经过的毫秒数都是相同的。（忽略相对论和任何关于闰秒的讨论...)
(旁注：在 Unix 时代，格林威治不是午夜。是凌晨 1 点，因为英国当时正在观察 BST。那是英国 标准时间，而不是英国时间 夏季 时间 - 从 1968 年 2 月 18 日到 1971 年 10 月 31 日，英国时间为 UTC+1。有关更多类似的琐事，请参阅 Noda Time user guide trivia page。）
是正确的。我会补充一些想法。
Unix time means different things to different people. As that Wikipedia article describes, the basic idea is usually a count of seconds since epoch, with epoch being the first moment of 1970 in the UTC 时区。顾名思义，这种时间跟踪方法曾用于类 Unix 操作系统。
地区
是否因地区而异？不是。根据定义，它代表 UTC 时区。所以 Unix 时间中的一个时刻意味着 Auckland, Paris, and Montréal 中的相同时刻。 UTC中的UT表示"Universal Time".
Unix 时间是否通用？不，当然不是。
粒度
首先，粒度。随着计算机时钟芯片变得更加精确，传统计算机系统将跟踪时间移动到 millisecond, microsecond, and even nanosecond. Different software assumes different granularity of time tracking. The java.util.Date/.Calendar classes and Joda-Time library both use millisecond resolution, while the newer java.time package built into Java 8 assumes nanosecond resolution. Some databases such as Postgres 通常采用微秒分辨率。
引用问题…
I am getting the UNIX time in milliseconds
技术上的矛盾，因为传统的 Unix 时间或 POSIX 时间是以整秒而不是毫秒来跟踪的。
纪元
其次，epoch. The first moment of 1970 is far from the only epoch used by various computer systems. A couple dozen epochs have been used, some with very wide usage. For example, Microsoft Excel and Lotus 1-2-3 spreadsheets, Cocoa, GPS satellites, Galileo satellites, DOS & FAT file systems, and ntp (Network Time Protocol) 每个使用不同的纪元，范围从 1899 年到 2001 年。
避免从纪元开始计数
通常最好避免通过从纪元开始计算毫秒（或任何粒度）来专注于处理日期时间值。这些值很难被人类阅读和理解，从而使调试变得困难并且错误不明显。加上上面讨论的关于粒度 and/or 时期的假设可能出现的错误。
而是使用像样的日期时间库。在 Java 中，这意味着：
您是否通过收集 7 或 8 位组来跟踪文本？不，您使用 类 和库来完成处理字符集、字符编码等的繁重工作。对日期时间工作做同样的事情。
我在网上做了一些调查，但仍然很困惑。 UNIX 时间是像 GMT/UTC 一样的通用时间还是像当地时间一样因地而异？
我知道 UNIX 时间是从 1970 年 1 月 1 日开始计算的 00:00:00 GMT。当我在 Java 中使用 getTime() 函数时（更具体地说 Date d= new Date(); long currentTime d.getTime()），我得到了以毫秒为单位的 UNIX 时间。现在如果A和B在两个不同的时区使用相同的功能，他们会得到相同的结果吗？
Now If person A and person B use the same function who are sitting in two different time zones, will they get the same result?
是的，他们会的 - 当然假设他们的时钟都是 "correct"。
java.util.Date class 基本上是 "the time since the Unix epoch, in milliseconds" 的包装。考虑到 Unix 纪元是 瞬间 时间（不仅仅是 "midnight on January 1st 1970"，无论你身在何处，经过的毫秒数都是相同的。（忽略相对论和任何关于闰秒的讨论...)
(旁注：在 Unix 时代，格林威治不是午夜。是凌晨 1 点，因为英国当时正在观察 BST。那是英国 标准时间，而不是英国时间 夏季 时间 - 从 1968 年 2 月 18 日到 1971 年 10 月 31 日，英国时间为 UTC+1。有关更多类似的琐事，请参阅 Noda Time user guide trivia page。）
Unix time means different things to different people. As that Wikipedia article describes, the basic idea is usually a count of seconds since epoch, with epoch being the first moment of 1970 in the UTC 时区。顾名思义，这种时间跟踪方法曾用于类 Unix 操作系统。
地区
是否因地区而异？不是。根据定义，它代表 UTC 时区。所以 Unix 时间中的一个时刻意味着 Auckland, Paris, and Montréal 中的相同时刻。 UTC中的UT表示"Universal Time".
Unix 时间是否通用？不，当然不是。
粒度
首先，粒度。随着计算机时钟芯片变得更加精确，传统计算机系统将跟踪时间移动到 millisecond, microsecond, and even nanosecond. Different software assumes different granularity of time tracking. The java.util.Date/.Calendar classes and Joda-Time library both use millisecond resolution, while the newer java.time package built into Java 8 assumes nanosecond resolution. Some databases such as Postgres 通常采用微秒分辨率。
引用问题…
I am getting the UNIX time in milliseconds
技术上的矛盾，因为传统的 Unix 时间或 POSIX 时间是以整秒而不是毫秒来跟踪的。
纪元
其次，epoch. The first moment of 1970 is far from the only epoch used by various computer systems. A couple dozen epochs have been used, some with very wide usage. For example, Microsoft Excel and Lotus 1-2-3 spreadsheets, Cocoa, GPS satellites, Galileo satellites, DOS & FAT file systems, and ntp (Network Time Protocol) 每个使用不同的纪元，范围从 1899 年到 2001 年。
避免从纪元开始计数
通常最好避免通过从纪元开始计算毫秒（或任何粒度）来专注于处理日期时间值。这些值很难被人类阅读和理解，从而使调试变得困难并且错误不明显。加上上面讨论的关于粒度 and/or 时期的假设可能出现的错误。
而是使用像样的日期时间库。在 Java 中，这意味着：
您是否通过收集 7 或 8 位组来跟踪文本？不，您使用 类 和库来完成处理字符集、字符编码等的繁重工作。对日期时间工作做同样的事情。