Dennis, > Depends upon the OS...
My apologies, its Linux (as on a Raspberry Pi). > You can easily look at the code used by psutil :-) I somehow assumed that those where build-in into the language itself. I'll have to take a peek at what else is available there too. > I read somewhere that the kernel calculates the btime from the > current gettimeofday minus the jiffies since boot converted to > seconds. That was also my guess to what happened. > last file system modification time > hardware RTC (if equipped) > NTP update (if networked) > what should your "boot time" be referenced against? The built-in clock ofcourse. :-) But I would not mind if it would be set to some believable time by the fake-hwclock. But granted, on a Raspberry thats a bit of a problem. On the other hand, just dragging the "last boot time" around by whatever time you now set feels like fakery. Oh man, I can already imagine a CSI plot where someone tries to use as linux machines boot time as an alibi, but summer time just arrived, causing it to appear an hour later .. :-) > but that boot time will depend on exactly when the CRON job ran > in relation to the three potential sources of clock time. I was already thinking of something similar (running a script at boot), but also saw such race-time problems. I might edit the fake-hwclock code though. Copying the clocks current date/time after it has just been set (or not, when an RTC is installed) would be enough for my purposes. ... Though I would rather not mess around in/with system files. Regards, Rudy Wieser -- https://mail.python.org/mailman/listinfo/python-list