On 11/6/19, Chris Angelico <ros...@gmail.com> wrote: > > Yes, but even if it's not recorded as a timestamp but as an uptime > counter, that counter can be referenced against the current time in > UTC. A DST switch affects the displayed time, but not the internal > definition of "current time" (at least, not on Linux, where the system > clock should be in UTC - the rules are different on Windows, and may > also be different on other Unix-like OSes);
Windows timestamps are UTC, but the epoch and base time unit are different from Unix. It uses the number of 100 ns intervals since 1601, instead of the number of seconds since 1970. psutil subtracts the value of GetTickCount64() from GetSystemTimeAsFileTime(), so changing the system time will change the reported boot time. But that's expected behavior. Even the kernel's KeBootTime value gets adjusted to account for the time delta when the system time is updated. Otherwise the system would be inconsistent. That said, the kernel (NT 5+) also also has a KeBootTimeBias value that tracks the net delta of KeBootTime from its original value. What psutil does should suffice, but if we need the kernel's exact boot time, without the expense and complexity of a WMI or perflib query, the native system call is NtQuerySystemInformation: SystemTimeOfDayInformation. This returns a SYSTEM_TIMEOFDAY_INFORMATION record, which includes BootTime and BootTimeBias fields. This query is implemented for internal use only, however. The fields and layout of the record are subject to change in future versions of Windows, so caveat emptor. To date, this record was only modified once, back in NT 5 (2000) to augment it with BootTimeBias and SleepTimeBias fields. -- https://mail.python.org/mailman/listinfo/python-list
