FileTime structv0.1.0

pub struct FileTime {
    pub lowDateTime: uint32;
    pub highDateTime: uint32;
}

Split across two 32-bit halves because the record predates a 64-bit integer being ordinary, and the halves are not aligned as one — FileTimeTicks joins them, and reading the pair as a uint64 is what a caller must not do. The epoch is not the Unix one. FileTimeToUnixEpochSeconds is the difference.

See also: https://learn.microsoft.com/windows/win32/api/minwinbase/ns-minwinbase-filetime

Fields

Related

FileTimeTicksPerSecond

pub const FileTimeTicksPerSecond: uint64 = 10000000;

How many FileTime ticks make one second. A FileTime counts 100-nanosecond intervals, so this is ten million. It is the conversion every wall-clock reading here needs.

Source

FileTimeToUnixEpochSeconds

pub const FileTimeToUnixEpochSeconds: uint64 = 11644473600;

Seconds between the FileTime epoch of 1601 and the Unix epoch of 1970. Windows counts from a different year than everything else, and this is what converts between them. The gap includes the leap days of the intervening centuries, which is why it is not a round number.

Source

FileTimeTicks

pub func FileTimeTicks(time: &FileTime) -> uint64

The whole 64-bit value a FileTime splits across two fields. time is borrowed and read, so callers pass the value directly. Win32 splits the count into a high and a low word because the structure predates 64-bit alignment guarantees; this puts it back together. Cannot fail. Runs in constant time and allocates nothing.

Source

Parameters

Returns: its two halves joined into one count of 100-nanosecond ticks since 1601