关于时间的那些事 - 文件的时间戳

在计算机中,每个文件都一个时间戳,之前遇到过一个关于文件时间戳的问题,这里记录下来分享给大家。

首先,遇到的问题的原型是:在一段Java程序中,通过Java的File.lastModified API去获得一个文件的时间戳,示例代码如下:

ClassLoader classLoader = DataMigrationController.class.getClassLoader();
URL url = classLoader.getResource("./application.properties");
File file = new File(url.toURI());
System.out.println(file + ": " + file.lastModified() + "->" + new Date(file.lastModified()));

URL url2 = classLoader.getResource("./bootstrap.properties");
File file2 = new File(url2.toURI());
System.out.println(file2 + ": " + file2.lastModified() + "->" + new Date(file2.lastModified()));

Date date = new Date();
System.out.println("current date: " + System.currentTimeMillis() + "->" + date);

当我在本地机器(成都)运行这段程序时,得到的结果如下:

application.properties: 1558083157000->Fri May 17 16:52:37 CST 2019

bootstrap.properties: 1558083157000->Fri May 17 16:52:37 CST 2019

current date: 1558083181463->Fri May 17 16:53:01 CST 2019

但是,当我把这段程序打好包(jar)部署到服务器上(两分钟之内),运行这段程序时,却得到如下结果(我expect得到的文件的时间戳和本地应该一致):

application.properties: 1558111956000->Fri May 17 16:52:36 UTC 2019

bootstrap.properties: 1558111956000->Fri May 17 16:52:36 UTC 2019

current date: 1558083328412->Fri May 17 08:55:28 UTC 2019

从上面的结果可以看出,得到的两个文件的时间戳比服务器上当时的时间还要晚,这很奇怪,怎么拿到了一个未来的时间?

起初怀疑是不是机器的时钟有问题。通过打印出来的当前时间来看,本地时间(Fri May 17 16:53:01 CST 2019)和服务器时间(Fri May 17 08:55:28 UTC 2019)是吻合的,说明时钟是没有问题。

后来发现,根本原因是压缩文件中的子文件的时间戳没有时区的信息,只有日期+时间的信息。具体出处可见(https://en.wikipedia.org/wiki/Zip_(file_format))中的一段话:

The ZIP format has no notion of time zone, so timestamps are only meaningful if it is known what time zone they were created in.

所以当在服务器上运行这段程序时,jar包解压,压缩文件里面的子文件的时间戳变成日期+时间+新的时区,即是我们看到的日期+时间没变,只是时区变成了服务器的时区UTC。

最后,下图展示了文件的时间戳在这个过程中的变化。

总结:当需要根据文件的时间戳来实现某些功能时,需要注意压缩文件中的子文件的时间戳没有时区的信息,只有日期+时间的信息

本文分享自微信公众号 - 天马行空布鲁斯(gh_2feda5c053bd)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-06

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券