std.os.windows: Change to handle Windows file time as u64 value

[sorairolake]

FILETIME structure stores a 64-bit unsigned integer value. The maximum value for this is "+60056-05-28 05:36:10.955161500 UTC". The maximum value of the FILETIME that FileTimeToSystemTime function accepts is "+30828-09-14 02:48:05.477580700 UTC". This is the same as the maximum value for a 64-bit signed integer or 63-bit unsigned integer types.

I've searched on these types and the timestamp of NTFS, and I think any value before "1601-01-01 00:00:00 UTC" is invalid. So I don't think we need to accept the negative Windows file time.

The maximum value of the NTFS timestamp and FileTimeToSystemTime function is "+30828-09-14 02:48:05.477580700 UTC", so u63 might be better than u64.

[alexrp]

I'm not overly familiar with the details here, but I'm not sure we can draw any useful conclusions just based on NTFS. What about ReFS, for example? Or for that matter, any future file system?

[sorairolake]

@alexrp Windows file time is defined as follows:¹

A file time is a 64-bit value that represents the number of 100-nanosecond intervals that have elapsed since 12:00 A.M. January 1, 1601 Coordinated Universal Time (UTC).

I'm not familiar with this. That this is an unsigned integer and that the maximum value is "+30828-09-14 02:48:05.477580700 UTC" or "+60056-05-28 05:36:10.955161500 UTC" is just a guess on my part based on the definition of FILETIME and the Wikipedia article for NTFS. I don't know about ReFS.

I don't know whether the correct maximum value is "+30828-09-14 02:48:05.477580700 UTC" or "+60056-05-28 05:36:10.955161500 UTC", since that's not stated in the documentation. However, the latter may be the maximum value by definition, since the FileTimeToSystemTime's documentation states:²

This value must be less than 0x8000000000000000. Otherwise, the function fails.

I chose u64 which can store a wider range of values ​​than u63 because FILETIME and 7z seem to store the timestamp as a 64-bit unsigned integer value. Even if the maximum value is actually 0x7_fff_fff_fff_fff_fff, it may be sufficient for the user to check in advance whether the value is within the valid range, as with the FileTimeToSystemTime function.

Footnotes

1. https://docs.microsoft.com/en-us/windows/win32/sysinfo/file-times ↩

2. https://learn.microsoft.com/en-us/windows/win32/api/timezoneapi/nf-timezoneapi-filetimetosystemtime ↩

[sorairolake]

By definition, any 64-bit unsigned integer is valid, but in practice in many places, I think it may be correct to recognize that the range of values ​​is restricted to positive 64-bit signed integer values.