Time shift

I don't know python, so I can't answer why the on-the-half-hour executions get the proper time, but the on-the-hour time discrepancy sounds like a time-zone "summer time" problem.

AIUT, Germany (or at least, parts of Germany) are now on "summer time", where the wall-clock time is one hour ahead of the "standard time" clock. It sounds like, for your on-the-hour execution, you are picking up "standard time" rather than "summer time".

I note that, from the python documentation at

Just a guess. Hope this helps you find the problem.

I had something similar ans used 29 and 59 minutes past the hour.

In your case why not try xx:00:15 and xx:30:15 or similar?

Dietmar,

Provide a bit more info and what you already tried yourself ?

-- More info : what does the minutes show in both cases ? Does it match the clock you are comparing the hours against ? If not ...

IOW, don't stare yourself blind on just the hours.

-- what you already tried yourself : what does the command

print( datetime.datetime.today() )

display ? Does it (closely) match the clock you are compar-- Suggestion : see if you can output "akdatum" to somewhere when the script is run as a cronjob and see if it matches the clock. If it doesn't ...

Regards, Rudy Wieser

Dietmar,

You know, I currently do not even know what you are using that code of yours for (creating a time-stamped file ?) and/or how you determined that the hour is (sometimes) wrong.

There is a chance you're misunderstanding what you are seeing, or looking at the wrong output. But with the rather meager info you supplied there is no way for us to figure any such thing out.

Which might well be why you have so few responses ...

Regards, Rudy Wieser

Hello Dietmar!

Sunday June 18 2023 21:52, you wrote to All:

Question's for you:

1. What times do you have ntp or/and ntpdate running ?
2. If not ntp then what are you using to update the system clock ?
3. Confirm that system is on 24/7 AND on stable main power.
4. Assuming you are using ntp what is the result of running sudo ntpstat For example the results of this for my system is :

synchronised to NTP server (85.199.214.98) at stratum 2 time correct to within 8 ms polling server every 1024 s

Vincent

As the the RPi already a built-in way, crond, of running periodic jobs at specified intervals, times or dates, why not write a simple bash script (or Python program).

Running the "man cron" command will tell you all about it.

Thank you Lew,

I also thought about timezones. But why it's OK at the 30 minutes time??!! I just updated to pytz on the Raspberry and wrote some lines with timezone-infos for Europe/Berlin.

In a few minutes I will see the result.

Dietmar.

Am 18.06.2023 um 11:22 schrieb R.Wieser:

Thank you Rudy,

what I tried was, to wait a few seconds in the Python-script: no success.

And I wrote in the Python-script the time values to a file. There are the wrong hours too. But the file has the correct timestamp. The RPi has timezone information (Europe/Berlin).

Now I try timezone information in the Python.

Dietmar.

It wouldn't be the first time a language-supplied library had some kind of bug in it.

Not a great Python coder, but can you essentially execute the Linux 'date' command and parse the output?

I have to say I've used date time functions in 'C' and never had an issue.

Dietmar Mysliwietz snipped-for-privacy@web.de schrieb:

Yeah, just an idea. Try in crontab

I don't think that there is a bug in the library. Where the problem is .. getting crazy

The date at the commandline returnes the correct time.

Dietmar.

Am 18.06.2023 um 16:23 schrieb Michael Schütz:

Thank you Michael,

that doesn't help. There was a time delay from 10 seconds in the Python at the begin.

Dietmar.

Am 18.06.2023 um 13:58 schrieb Dietmar Mysliwietz:

I wrote some Phyton-lines: datum = datetime.datetime.now() datum2 = datetime.datetime.now(pytz.timezone('Europe/Berlin'))

.. and called this script via cronjob at 0,30 * * * *

This script returne the correct time, my 'old big' script didn't.

Dietmar.

Dietmar,

It looks like the different accounts (users) can have their own timezones.

Suggestion : see, to verify the above assumption, what "utcoffset" and "tzname" return for both the crontab user as well as you as a user.

Dietmar,

Thats a good thought, as problems are seldom caused by bugs. More often its just a simple misunderstanding something.

I think you're going in the right direction. The only thing that needs to be done is to verify it.

... and even if not the right direction, trying to understand what happens is /way/ better than directly trying to "work around" it (and there is a good chance that the suggested work around would return the exact same "wrong" result).

Can you execute that thru the crontab and check (write to a file and compare its timestamp with the date thats written into it) ? It would be another confirmation of my assumption that the crontab account works with a different timezone - or sould I say "works under UTC", as that is a good way not to get into trouble with summer/winter time changes. But it bites you in the a** when you're not aware of it - like now.

A quick DDG search for "linux crontab which timezone" returned the below :

This has been a standard feature of unix since timezone support first appeared. It was not uncommon for multi-user systems with remote access to have users in multiple timezones who naturally want to see their own local time and not that of the machine room.

Ahem,

Thanks for the confirmation.

And it shows how little I actually know about Linux.

I already figured that that would be the logic behind having it. :-)

Regards, Rudy Wieser

Am 18.06.2023 um 20:10 schrieb R.Wieser:

Thanks again Rudy,

I will tray to figure it out tomorrow.

Thanks a lot to all others.

Have a good night.

Dietmar.

I'm puzzled by this. How about trying cron jobs started at xx:01, xx:02, ... xx:58, xx:59 to see at what point the hour changes from being incorrect to being correct.

I presume if you call your Python program manually (as opposed to from cron) it gives the correct time even if you call it at xx:00:00.