【问题标题】:java display Windows UTC timejava显示Windows UTC时间
【发布时间】:2011-07-09 03:22:26
【问题描述】:

Windows 内部将 FileTime 存储为自 1.1.1601 UTC 以来的 100 纳秒数作为 64 位字段,是否可以让 java 打印出当前数字?只是寻找一个例子,因为我找不到办法。我想把号码打印出来?

任何帮助都会很棒!

谢谢。

【问题讨论】:

  • 这里有什么问题?获取文件、读取文件还是打印?
  • 您是否看过本网站上的以下主题? [stackoverflow.com/questions/32586/…这是你想要的还是有别的东西?

标签: java printing time utc


【解决方案1】:

大概

long diff1601to1970 = 315532800 * 1000000000; // <-- diff in nanoseconds(1/1/1601 to 1/1/1970)
long currentFrom1970 =  System.currentTimeMillis() * 1000000;
long currentFrom1601 = diff1601to1970 + currentFrom1970;

【讨论】:

    【解决方案2】:

    Java 不提供对原始文件时间的直接访问,因此如果您要求lastModified 时间

    someFile.lastModified();
    

    您将获得文件上次修改的时间,以自纪元(格林威治标准时间 00:00:00,1970 年 1 月 1 日)以来的毫秒数为单位,如果文件不存在或发生 I/O 错误,则为 0L

    并非每个平台都跟踪与文件相关的“相同”时间,并且它们在内部跟踪文件的方式也不同。 Java 尝试从不同的标准中创建一个连贯的平台的部分尝试使用多态性将平台特定时间转换为幕后的“java 标准”。

    现在将返回的毫秒转换为 java 时间:

    java.util.Date date = new java.util.Date(millis);
    

    从那里您可以使用标准 i/o 例程来显示和格式化日期(DateFormat 等)

    PS。 1601 年 1 月 1 日最初被 COBOL 选为时代,并被微软(可能还有其他人)模仿。选择它的原因是因为它是操作系统发布时 400 年公历周期的开始。每 400 年,闰年的模式就会重演一次。

    【讨论】:

    • 即使您决定尝试“反向计算”大概的 WINTIME 日期,您也无法确保它是正确的时间,因为 Java 的最佳测量单位是毫秒,而 WINTIME 的最佳单位是测量值更小。信息在转换为 java epoch 标准时丢失了,在这种情况下,它丢失了文件感知毫秒的小数部分。
    猜你喜欢
    • 1970-01-01
    • 2022-06-16
    • 2015-04-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2022-06-10
    • 1970-01-01
    相关资源
    最近更新 更多