问题标签 [filetime]

我在 VS 2017 中有一个基本的 C++/CLI DLL，它定义了下面描述的包装类。项目属性设置为以 .NET 4.6.1 作为目标生成 CLR。

我需要重用包含自身 windows.h 的 C++ 文件（handler.h，来自 API devkit），主要是为了使用 HANDLE 和 CRITICAL_SECTION 结构。我知道这一点是因为如果我删除了 handler.h 标头中的 windows.h 包含（以及使用上述结构的大部分代码），CLI 包装器 DLL 编译得很好。

问题是 FILETIME 是在 windows.h (minwinbase.h) 包含的头文件之一和命名空间 System::Runtime::InteropServices 中定义的。该错误在 VS 2017 中报告为 E0266，并带有指向线程的链接，该线程建议使用预期的使用范围 (::FILETIME) 限定 FILETIME 的使用。然而，在这种情况下这是不可能的，因为此标头来自操作系统。我还需要使用 System 命名空间，因为它是 CLI 组装机制的基础。

如何解决这个冲突？有没有办法不使用系统命名空间的给定部分？有什么方法可以指示编译器如何解决冲突？

我要分析一批 SAS 程序文件，我被困在获取程序文件的最后修改时间。我曾考虑过X命令，但效率太低了。
我只是在使用infile语句时发现：

日志显示最后修改时间：

如您所见，日志窗口将文件信息显示为注释。但是，我希望输出是一个用 Last Modified Time 填充的变量。

infile使用语句时是否有一些选项可以获取它？当然，也欢迎其他有效的方式。

在 .NET 中写了一些东西；它运作良好。现在我正在尝试使用 Win32 API 将其重写为 shell 扩展。最终我想将FILETIMEs 转换为 ISO-8601 字符串和从 ISO-8601 字符串转换。这是可行的，无需大惊小怪，使用GetTimeZoneInformationandFileTimeToSystemTime和SystemTimeToTzSpecificLocalTimeand将and结构StringCchPrintf的成员组装成一个字符串。SYSTEMTIMETIME_ZONE_INFORMATION

像往常一样使用日期/时间时，问题是夏令时。UsingGetTimeZoneInformation告诉我现在生效的 UTC 偏移量。使用 .NETDateTime.ToString("o")会考虑DateTime 中表示的时间的夏令时。

相同示例FILETIME：
输出ToString("o")：2017-06-21T12:00:00.0000000-05:00
链式 API 的输出：2017-06-21T12:00:00-06:00

来自链式 API 调用的 UTC 偏移量是错误的。.NET 是如何DateTime做到的？我们如何在 Win32 中复制它？有没有类似的东西GetTimeZoneInformationForYear，但不是一年，而是本地时间的片刻？

FILETIME 作为数据记录的绝对时间戳似乎是一个不错的选择，

有人知道如何使 FILETIME 在 Raspberry Pi 上工作吗？

FILETIME 计算自 1601 年 1 月 1 日以来的百纳秒数（0.1 us 单位）。

据我所知，Raspberry Pi 有一个 64 位微秒计数器 (Pi_Counter)，它在设备通电时开始计数。Raspberry Pi 还有一个使用 NTP 初始化的 Pi_Clock（如果启用且可用）和/或电池驱动的实时时钟。鉴于此，看起来我们可以通过以下方式在 Raspberry Pi 上生成 FILETIME：

FILETIME= Pi_Counter*10 + Actual_Init_Constant；其中，Actual_Init_Constant 计算为（1601 年 1 月 1 日）、Pi_Clock（实际时间）和 (Pi_Counter) 之间的总和和差，均转换为百纳秒（0.1 us 单位）。

有人知道如何使它工作吗？

我有一堆图像和视频文件，想在 Windows 中按创建日期对它们进行排序。在 Windows-Explorer 中，我看到一个显示正确日期的列“日期”，我所有的测试文件都是从 2019 年开始的。但是使用 php，我似乎无法获得这个日期：使用 filemtime、filectime 或 fileatime，我只得到 2021 年 8 月的日期。

Windows 从哪里获得正确的日期以及如何在 php 中获得它？

我忘了为这个问题添加动机。使用 FileTimeToSystemTime 的明显解决方案非常慢，这个函数比慢速 API 调用快 3 倍以上。作为精密计时项目的一部分，我开发了 VBA 代码来从 FILETIME (FT) 数据中提取 YEAR 信息。我可以改进测试这段代码吗？算法是：

1. 从 FT 数据中提取整数天数
2. 估计年份除以每年的平均天数（(365*400+100-3)/400=365.2425 天/年）。这是正确的答案 +/- 一年。
3. 考虑闰年，计算截至 1 月 1 日和 12 月 31 日今年的确切天数。
4. 如果实际的天数 (1) 在这两个数字之间，则 2) 中的估计是正确的。如果不正确，则添加或减去一年以获得正确的年份，其中包括 1) 中的天数。

为了测试代码，我创建了一个随机的 SYSTEMTIME (ST) 日期/时间，使用 SystemTimeToFileTime 将此日期转换为 FT 刻度，然后运行提取函数。我知道输入年份，所以我可以验证提取的年份等于输入年份。我循环运行了测试代码。当我的笔记本电脑没有受到限制时，我可以每秒查看大约 12K ST 测试。我已经运行了一百万个随机样本，没有错误。

我担心这还不够好测试，因为我已经阅读了很多关于使用日期的内容，对于这么多时区、国家、任意本地更改问题等问题如此之多。这是足够好的测试，还是我应该做其他事情，比如尝试做一些闰年测试或夏令时测试（我不知道该怎么做）。提取和测试代码：

如何在 Windows 上使用 PowerShell 以 Windows FILETIME格式获取当前时间？

除了 Windows，使用 Windows 格式（64 位值表示自 1601 年 1 月 1 日 UTC 以来的 100 纳秒间隔数），类似于这个关于 Linux 的答案，FILETIME最好是像上述答案一样简单。