JAVA UTC时间的基准点问题

Posted 2023-04-04

System.currentTimeMillier(), 拿到的是当前时间和一个基准点（1970年1月1日午夜）之间的差值。想请教大神，这个基准点全世界共用一个，还是说在中国调用这个方法时这个基准点是东八时区的1970年1月1日午夜，在其他地方调用这个方法时用的是当地时区的1970年1月1日午夜？

TimeZone这方面已经要把楼主弄傻了。。。
谢谢大神

计算机用的是unix纪元，1970年1月1日 0时0分 UTC(协调世界时 即升级版的格林威治时间)
可以说是英国标准时间。

中国是UTC+8 八区，中国本地时间要在以上标准时间上面加8小时。

反映在java的timemilli毫秒时是，
long china_ts=System.currentTimeMillier()+1000*60*60*8;
但只在不支持Java SE时区的早期版本(比如Java Card，Java ME/MIDP1.0)才需要自己手工加。
现在的java系统本身有时区库，用Calendar/Date类，会自动调整时区。不需要再手动算。按以上加法会画蛇添足。 参考技术A 基准点是所谓的“UNIX epoch”, 指的是一个客观固定的时间点，即UTC的1970年1月1日午夜。尽管地球上不同地方的地方时不一样，但是这不影响客观时间时间尺度。 参考技术B 　　你好，很高兴能够给你解答问题，Java中System.currentTimeMillier()是指获取你电脑的当前时间距基准点（1970年1月1日午夜）的差值，并不是说在中国或者在其他国家调用就不一样，你可以设置你的电脑时间在程序测试一下，学习要灵活，切记不能死搬硬套

　　希望可以帮助到你

为啥 GMT 是计算机时间的标准而不是 UTC？

【中文标题】为啥 GMT 是计算机时间的标准而不是 UTC？

【英文标题】：Why is GMT the standard for computer time instead of UTC?为什么 GMT 是计算机时间的标准而不是 UTC？

【发布时间】：2012-02-14 11:55:10

【问题描述】：

在我看来，就像我在编程中看到与时间相关的算法的所有地方一样，GMT 是基准时间。例如，有人告诉我始终将时间存储在 GMT+00 的数据库中，这样时区更改就不会中断任何事情。

GMT 似乎是软件开发中的基准时区，我说得对吗？

如果是这样，为什么不是 UTC？考虑到即使是 Unix 时间戳也是从 UTC 定义的 (http://en.wikipedia.org/wiki/Unix_time)

，为什么不常见说“UTC+01”而不是“GMT+01” >

【问题讨论】：

我相信 GMT 和 UTC 是一样的。不同之处在于定义它们的组织名称。英国时间（GMT = 格林威治子午时间）早于国际时间（UTC）。见en.wikipedia.org/wiki/UTC

因为 UTC 是法语而 GMT 是英语？

常用UTC+01:List of time zone abbreviations,List of time zones by UTC offset

@arx，你错了！见UTC History

我的错误：我认为 UTC 是法语的缩写，但它是英语 CUT 和法语 TUC 之间的折衷。

【参考方案1】：

GMT 和 UTC 是同一时间。 UNIX 时间基于 UTC，因此您可能会在 UNIX 和 *nix 系统上发现更多信息。

UTC 也更紧密地作为官方时间进行跟踪（即更接近基于地球自转的“真实”时间）。但是，除非您的软件需要精确计算，否则使用 GMT 或 UTC 应该没有区别。

不过，您可能会考虑向用户显示哪些内容。一种格式可能比另一种更熟悉。对于全球应用程序，我通常会使用 UTC，而对于欧洲或英国的应用程序，我会使用 GMT。

【讨论】：

轻微修正：根据en.wikipedia.org/wiki/Coordinated_Universal_Time，UTC 是基于原子钟的，而不是像 UT1 和 GMT 那样在技术上基于地球自转。但是经过研究，我现在发现，如果您不关心亚秒级精度，那么 GMT 与 UTC 相同。

@Thr4wn UTC 和 TAI 是协调的，但它们之间的间隔超过 30 秒。这是因为 UTC 偶尔会增加闰秒以保持在 UT1 的一秒内。我认为这是准确性与精确度的问题。 UTC 和 TAI精确相隔 34 秒，但 UTC 和 UT1 更准确相关（在 1 秒内）。

【参考方案2】：

这个接受的响应实际上是错误的。首先，它们无论如何都不相同。第二个UTC与基于地球自转的“真实”时间并没有更接近，恰恰相反。 UTC 在“时间”度量方面更精确。每一秒都是一样的，因为是基于原子时间的，精度高得令人难以置信（抵消一秒需要3万年）。

格林威治标准时间跟踪地球自转，因为这并不总是相同的（地球自转正在减慢），每一秒都不同。当然，在很短的时间内会有所不同。但出于科学目的，UTC 比 GMT 准确得多。

这就是 UTC 每 4/5 年变化 +2 秒的原因（因为地球自转速度较慢，自转所需的时间必须大于 UTC），因此它跟随 GMT 地球自转时间不到一秒的区别。

【讨论】：

仅供参考 - 您描述的是 UT1，而不是 GMT。 Wikipedia says it quite well：“......今天，对于英国的民用目的，GMT 被认为等同于 UTC......而对于导航，则被认为相当于 UT1......”

【参考方案3】：

我认为发现 IANA timezones 目前使用缩写“GMT”会很有趣，无论是现在还是从现在起 6 个月后（以赶上那些目前处于夏令时的人）。

使用这个free, open source C++11/14 library，我编写了这个程序：

#include "tz.h"
#include <string>
#include <iostream>
#include <vector>

template <class Duration>
std::vector<date::zoned_time<std::common_type_t<Duration, std::chrono::seconds>>>
find_by_abbrev(date::sys_time<Duration> tp, const std::string& abbrev)

    using namespace std::chrono;
    using namespace date;
    std::vector<zoned_time<std::common_type_t<Duration, seconds>>> results;
    auto& db = get_tzdb();
    for (auto& z : db.zones)
    
        if (z.get_info(tp).abbrev == abbrev)
            results.push_back(make_zoned(&z, tp));
    
    return results;


int
main()

    using namespace std::chrono;
    using namespace date;
    auto now = system_clock::now();
    auto v = find_by_abbrev(now, "GMT");
    for (auto const& x : v)
        std::cout << format("%F %H:%M:%S %Z %z", x) << " "
                  << x.get_time_zone()->name() << '\n';
    std::cout << '\n';
    v = find_by_abbrev(now + months6, "GMT");
    for (auto const& x : v)
        std::cout << format("%F %H:%M:%S %Z %z", x) << " "
                  << x.get_time_zone()->name() << '\n';

这会在地球上搜索当前使用“GMT”的所有时区，包括现在和 6 个月后，并将它们打印出来：

2016-06-18 01:00:25.632773 GMT +0000 Africa/Abidjan
2016-06-18 01:00:25.632773 GMT +0000 Africa/Accra
2016-06-18 01:00:25.632773 GMT +0000 Africa/Bissau
2016-06-18 01:00:25.632773 GMT +0000 Africa/Monrovia
2016-06-18 01:00:25.632773 GMT +0000 America/Danmarkshavn
2016-06-18 01:00:25.632773 GMT +0000 Atlantic/Reykjavik
2016-06-18 01:00:25.632773 GMT +0000 Etc/GMT

2016-12-17 15:55:01.632773 GMT +0000 Africa/Abidjan
2016-12-17 15:55:01.632773 GMT +0000 Africa/Accra
2016-12-17 15:55:01.632773 GMT +0000 Africa/Bissau
2016-12-17 15:55:01.632773 GMT +0000 Africa/Monrovia
2016-12-17 15:55:01.632773 GMT +0000 America/Danmarkshavn
2016-12-17 15:55:01.632773 GMT +0000 Atlantic/Reykjavik
2016-12-17 15:55:01.632773 GMT +0000 Etc/GMT
2016-12-17 15:55:01.632773 GMT +0000 Europe/Dublin
2016-12-17 15:55:01.632773 GMT +0000 Europe/London

我很高兴看到在所有情况下 UTC 偏移量都是+0000。你永远不知道政治家和时区。一些立法机构可以很容易地宣布“绿山时间”（明天就可能）。

【参考方案4】：

GMT 和 UTC 不是一回事。阅读 https://en.wikipedia.org/wiki/Greenwich_Mean_Time 以及其中指向 UTC 的链接以了解区别。

一些计算机用户对在 Windows 7 之前没有完全支持 UTC 的 Microsoft 操作系统这一事实感到困惑，因此一直将国际时间参考标记为 GMT。

关键问题是 Windows 如何读取和设置 BIOS 时钟。 Windows XP 无法处理将 BIOS 时钟设置为 UTC，因此您必须将 BIOX 时钟设置为本地时间，然后依靠 Windows 跟踪差异。

从 Windows 7 开始，Windows 可以将 BIOS 时钟设置为 UTC，并且所有计算（大部分？）都与 UTC 一致，因此 Microsoft 决定将标签从 GMT 切换为 UTC。

见：

https://superuser.com/questions/185773/does-windows-7-support-utc-as-bios-time

【讨论】：

关于 Windows 的部分不正确。标签从 GMT 更改为 UTC 仅仅是因为 Microsoft 认识到 UTC 是更准确的术语。它与可以或不可以支持的内容无关。在 Windows 7 中没有对时间处理进行任何功能更改。一些细节 in this article 表明 RealTimeIsUniversal 至少从 Windows 2000 开始就存在，并且可能在此之前（回到 Windows NT）。

【参考方案5】：

我会说这是因为大多数人都习惯了 GMT。如果你要向一个人显示信息，特别是时间，你会想要一种他们容易理解的格式。使用 GMT 为您节省了转换为 UTC 和返回的额外步骤。

【讨论】：

GMT 和 UTC 是同一事物的不同名称。没有什么可以转换的。

@arx，这是同一时间，但不是同一件事！

那么，如果有区别，那么两者之间肯定有某种转换，对吧？

不同之处在于 GMT 与 UTC 相比不精确，因此无法进行转换。根据en.wikipedia.org/wiki/Coordinated_Universal_Time，“”“格林威治标准时间（GMT）一词在亚秒级没有精确定义，但通常被认为等同于UTC或UT1。说“GMT”通常意味着UTC或UT1在非正式或随意的环境中使用。在技术环境中，避免使用“GMT”；明确的术语“UTC”或“UT1”是首选。“””

根据这个en.wikipedia.org/wiki/Time_zone#Definition（该部分的倒数第二段，引用了1983年的文件）GMT被正式定义为与UTC相同。唯一需要的转换是将格式字符串中的“UTC”更改为“GMT”。