使用统计API获取不正确的文件修改时间

在获取文件的修改时间时，我看到一个奇怪的行为。 我们一直在调用_stat64方法来获取我们项目中的文件修改如下。

int my_win_stat( const char *path,struct _stati64 *buf) { if(_stati64( path,buf) == 0) { std::cout<<buf->st_mtime << std::endl; //I added to ensure if value is not changing elsewhere in the function. } ........... ........... }

当我使用epoch转换器转换由st_mtimevariables返回的epoch时间时，它显示比我的系统上设置的当前时间提前2:30。

当我从不同的testing项目调用相同的API，我看到正确的mtime（即根据我的系统显示的文件的mtime）。

if (_stat64("D:\engine_cost.frm",&buffer) == 0) std::cout << buffer.st_mtime << std::endl;

即使我调用了GetFileTime（），并在本文的帮助下将FILETIME转换为了纪元时间。 我根据时间设定系统得到正确的时间。

用于Windows开发的GStreamer或DirectShow？

MIPS可执行文件/目标文件格式

使用DLL名称获取表单数据

我如何使用C＃读取扩展智能数据？

如何在运行时将参数放入函数中？

if (GetFileTime(hFile,&ftCreate,&ftAccess,&ftWrite)) { ULARGE_INTEGER ull; ull.LowPart = ftWrite.dwLowDateTime; ull.HighPart = ftWrite.dwHighDateTime; std::cout << (ull.QuadPart / 10000000ULL - 11644473600ULL); }

我无法弄清楚的是，为什么现在的项目调用时间不同？

什么是可能影响mtime输出的参数？

还有什么我可以尝试进一步debugging问题？

注意

在VS2013中，_stati64是一个被replace为_stat64的macros。

文件系统是Windows 7上的NTFS。

哪一个是你使用过的最可靠，最快的Windows C ++分析器？

通过netlink发送一个从内核到用户空间的结构

gdb“watch”不能通过glibc（read）函数修改variables吗？

如何访问使用C / C ++编写的函数到ruby脚本？

在Linux中显式导出共享库函数

Unix时间真的很容易处理。 这是自1970年1月1日以来的秒数（即0代表特定日期）。

现在，你所说的是，你正在用浏览器中的第三方工具来测试你的时间（mtime），并期望给你正确的答案。 所以…让我们做一个测试，下面的数字是2015年9月1日格林尼治标准时间00:00:00。

1441065600

如果你去大纪元转换器，并使用它的价值，它是否给你正确的GMT？ （如果不是的话，那么确实是错的。）然后看看当地的时间值，看看你是否能得到你所期望的北京时间午夜。 （请注意，我使用GMT，因为Epoch Converter使用这个缩写，但正确的缩写是UTC。）

在我看来，你的代码很可能会提取正确的时间，但是在本地时间内，时代转换器会在你的计算机上失败。

请注意，你可以在你的C ++程序中测试这样的东西：

std::cerr << ctime(&buf->st_mtime) << std::endl;

（只要注意ctime（）不是线程安全的）

这将在运行时根据您的计算机上的语言环境为您提供数据。

为了更好地控制日期格式，使用strftime（） 。 该函数使用tm结构，因此您必须首先调用gmtime或localtime 。

一年后，我遇到了类似的问题，但情况是有点不同。 但是这次我明白为什么还有一个+2：30的差距。 我通过perl脚本执行C ++程序，实习生设置时区'GMT-3' ，我的机器已经在时区“GMT + 5：30”。 结果是“2:30”的差异。 为什么？ 正如Harry在这篇文章中所提到的

在Perl中更改时区可能会导致设置TZ环境变量，这会影响C运行时库， 如_tzset文档所示 。