Dennis,
> However -- manually changing date/time is not going to illustrate this.
> ANY change made to date/time will reflect a change in UTC time.
It turns out that the get_uptime() does /not/ calculate the boottime from
the current clock minus the uptime. Its a seconds-since-epoch (absolute!)
Dennis,
> Well... If it is the last file written during shutdown, it would be
> the "last file system modification time"
Yep ... up until the next hours cronjob overwriting it ...
Currently I've got a (very) small init.d shellscript which copies the
contents of that file into another one - whi
On Fri, Nov 8, 2019 at 1:24 AM R.Wieser wrote:
>
> Chris,
>
> > 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.
>
> Absolutily. Though the keyword here is "can". My "could easily imagine"
> consi
Chris,
> 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.
Absolutily. Though the keyword here is "can". My "could easily imagine"
considers the other possibility.
I guess I should sit down sometime
Dennis,
> Which is probably... last file system modification time
Nope. Its from a file it saves at shutdown, and which gets updated once an
hour (I also thought of that one, but the once-an-hour update threw a wrench
into it).
> There is no way for a freshly booted system to differentiate be
On Wed, Nov 6, 2019 at 7:54 PM Terry Reedy wrote:
> I don't know how much Linux is customized for RP, but last I knew,
> Python on RP is MicroPython, not CPython. So I expect OS-related
> functions to not necessarily match Linux on a desktop.
The default OS on all Raspberry Pi models is Raspbian
On 11/6/19, Chris Angelico 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
On 2019-11-06 22:53, Terry Reedy wrote:
On 11/6/2019 3:09 PM, R.Wieser wrote:
Dennis,
Depends upon the OS...
My apologies, its Linux (as on a Raspberry Pi).
I don't know how much Linux is customized for RP, but last I knew,
Python on RP is MicroPython, not CPython. So I expect OS-related
f
On Thu, Nov 7, 2019 at 9:55 AM Terry Reedy wrote:
>
> On 11/6/2019 3:09 PM, R.Wieser wrote:
> > Dennis,
> >> Depends upon the OS...
> >
> > My apologies, its Linux (as on a Raspberry Pi).
>
> I don't know how much Linux is customized for RP, but last I knew,
> Python on RP is MicroPython, not CPyt
On 11/6/2019 3:09 PM, R.Wieser wrote:
Dennis,
Depends upon the OS...
My apologies, its Linux (as on a Raspberry Pi).
I don't know how much Linux is customized for RP, but last I knew,
Python on RP is MicroPython, not CPython. So I expect OS-related
functions to not necessarily match Linux
On Thu, Nov 7, 2019 at 7:31 AM R.Wieser wrote:
>
> Chris,
>
> > I don't think boot time would be affected by a DST switch, though.
> > It should be recorded in UTC.
>
> The point is, it /isn't/ a recorded constant (at least not on my machine).
> Its just dragged around with the clocks current time
On Thu, Nov 7, 2019 at 7:21 AM R.Wieser wrote:
>
> Chris
>
> > That's possibly because you're looking at psutil, which is a third
> > party package. Here's its documentation:
>
> My info came frome here:
> https://www.programcreek.com/python/example/53873/psutil.boot_time
>
> Looking at example 1
Chris,
> I don't think boot time would be affected by a DST switch, though.
> It should be recorded in UTC.
The point is, it /isn't/ a recorded constant (at least not on my machine).
Its just dragged around with the clocks current time (as in: current time
minus uptime). And as such I could e
Chris
> That's possibly because you're looking at psutil, which is a third
> party package. Here's its documentation:
My info came frome here:
https://www.programcreek.com/python/example/53873/psutil.boot_time
Looking at example 1 it looks the be the same.
> But I don't know what its definition
On Thu, Nov 7, 2019 at 7:16 AM R.Wieser wrote:
> 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
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
On Thu, Nov 7, 2019 at 6:11 AM R.Wieser wrote:
>
> I also tried to google "python BOOT_TIME", but got nowhere (the latter parts
> casing was ignored). Hence me posting here.
>
That's possibly because you're looking at psutil, which is a third
party package. Here's its documentation:
https://psu
Maxime,
> You may want to read PEP 418 which nicely summaries the
> different clock available on each platform and their limitations.
You mean the CLOCK_REALTIME and CLOCK_MONOTONIC ones ? Yeah, that was what
I was looking at :-)
> It looks like CLOCK_BOOTTIME is what you want but it is only
>
Hello,
You may want to read PEP 418 which nicely summaries the different clock
available on each platform and their limitations.
It looks like CLOCK_BOOTTIME is what you want but it is only available on
Linux.
Regards,
Maxime.
Le mer. 6 nov. 2019 à 18:23, R.Wieser a écrit :
> Hello all,
>
>
Hello all,
I was doing a "lets print some time-related data", and also diaplayed the
result of "psutil.boot_time()".
Somewhere while doing that I saw that my clock was off, so I used the "date"
command to rectify it.
The thing is, after that the result of "psutil.boot_time()" was changed -
and t
20 matches
Mail list logo
