Hallo,

I have a python-script which is called at 0 and 30 minutes at every hour
from a cronjob:

0,30 * * * * sudo python3 /*****

In the script I call the current time:

akdatum = datetime.datetime.today()
akzeit = akdatum.time()
akzeitstr = akzeit.strftime('%H:%M')

At 0 minutes the returned hour is one hour BEFORE the real hour.
At 30 minutes the returned hour is the correct hour.

Any ideas ?

Thank you.

Dietmar.

On Sat, 17 Jun 2023 16:53:23 +0200, Dietmar Mysliwietz wrote:

> Hallo,
>
> I have a python-script which is called at 0 and 30 minutes at every hour
> from a cronjob:
>
> 0,30 * * * * sudo python3 /*****
>
> In the script I call the current time:
>
> akdatum = datetime.datetime.today()
> akzeit = akdatum.time()
> akzeitstr = akzeit.strftime('%H:%M')
>
> At 0 minutes the returned hour is one hour BEFORE the real hour.
> At 30 minutes the returned hour is the correct hour.
>
> Any ideas ?

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
https://docs.python.org/3/library/datetime.html,
datetime.datetime.today() will "Return the current local
datetime, with tzinfo None." As I said, I don't know
python, so I don't know the impact of "tzinfo None". But...
as "summer time" offsets are usually part of the tzinfo,
perhaps this "tzinfo None" is interfering with your
"summer time" time conversion.

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

--
Lew Pitcher
"In Skills We Trust"

On 17/06/2023 15:53, Dietmar Mysliwietz wrote:
> Hallo,
>
> I have a python-script which is called at 0 and 30 minutes at every hour
> from a cronjob:
>
> 0,30 * * * * sudo python3 /*****
>
> In the script I call the current time:
>
> akdatum = datetime.datetime.today()
> akzeit = akdatum.time()
> akzeitstr = akzeit.strftime('%H:%M')
>
> At 0 minutes the returned hour is one hour BEFORE the real hour.
> At 30 minutes the returned hour is the correct hour.
>
> Any ideas ?
>
> Thank you.
>
> Dietmar.

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?

--
Cheers,
David
Web: https://www.satsignal.eu

Dietmar,

> I have a python-script which is called at 0 and 30 minutes at every hour
> from a cronjob:
>
> 0,30 * * * * sudo python3 /*****
>
> In the script I call the current time:
>
> akdatum = datetime.datetime.today()
> akzeit = akdatum.time()
> akzeitstr = akzeit.strftime('%H:%M')
>
> At 0 minutes the returned hour is one hour BEFORE the real hour.
> At 30 minutes the returned hour is the correct hour.
>
> Any ideas ?

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 comparing the hours
against ?

I've taken your code and printed "akdatum" as well as "akzeitstr". The
hours and minutes match. IOW, the problem might very well not in the code
you posted ...

-- 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,

"R.Wieser" <address@is.invalid> wrote in message
news:u6mbsm$1jqm6$1@dont-email.me...
....
> Provide a bit more info

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

On Sat, 17 Jun 2023 16:53:23 +0200, Dietmar Mysliwietz wrote:

> Hallo,
>
> I have a python-script which is called at 0 and 30 minutes at every hour
> from a cronjob:
>
> 0,30 * * * * sudo python3 /*****
>
> In the script I call the current time:
>
> akdatum = datetime.datetime.today()
> akzeit = akdatum.time()
> akzeitstr = akzeit.strftime('%H:%M')
>
> At 0 minutes the returned hour is one hour BEFORE the real hour.
> At 30 minutes the returned hour is the correct hour.
>
> Any ideas ?
>
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.

--

Martin | martin at
Gregorie | gregorie dot org

Am 17.06.2023 um 18:13 schrieb Lew Pitcher:
> On Sat, 17 Jun 2023 16:53:23 +0200, Dietmar Mysliwietz wrote:
>
>> Hallo,
>>
>> I have a python-script which is called at 0 and 30 minutes at every hour
>> from a cronjob:
>>
>> 0,30 * * * * sudo python3 /*****
>>
>> In the script I call the current time:
>>
>> akdatum = datetime.datetime.today()
>> akzeit = akdatum.time()
>> akzeitstr = akzeit.strftime('%H:%M')
>>
>> At 0 minutes the returned hour is one hour BEFORE the real hour.
>> At 30 minutes the returned hour is the correct hour.
>>
>> Any ideas ?
>
> 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
> https://docs.python.org/3/library/datetime.html,
> datetime.datetime.today() will "Return the current local
> datetime, with tzinfo None." As I said, I don't know
> python, so I don't know the impact of "tzinfo None". But...
> as "summer time" offsets are usually part of the tzinfo,
> perhaps this "tzinfo None" is interfering with your
> "summer time" time conversion.
>
> Just a guess. Hope this helps you find the problem.
>

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:
> Dietmar,
>
> "R.Wieser" <address@is.invalid> wrote in message
> news:u6mbsm$1jqm6$1@dont-email.me...
> ...
>> Provide a bit more info
>
> 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
>
>

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.

On 18/06/2023 12:58, Dietmar Mysliwietz wrote:
> Am 18.06.2023 um 11:22 schrieb R.Wieser:
>> Dietmar,
>>
>> "R.Wieser" <address@is.invalid> wrote in message
>> news:u6mbsm$1jqm6$1@dont-email.me...
>> ...
>>> Provide a bit more info
>>
>> 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
>>
>>
>
> 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).
>
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.

> Now I try timezone information in the Python.
>
> Dietmar.

--
In a Time of Universal Deceit, Telling the Truth Is a Revolutionary Act.

- George Orwell

Dietmar Mysliwietz <dmysliwietz@web.de> schrieb:
> Hallo,
>
> I have a python-script which is called at 0 and 30 minutes at every hour
> from a cronjob:
>
> 0,30 * * * * sudo python3 /*****
>
> In the script I call the current time:
>
> akdatum = datetime.datetime.today()
> akzeit = akdatum.time()
> akzeitstr = akzeit.strftime('%H:%M')
>
> At 0 minutes the returned hour is one hour BEFORE the real hour.
> At 30 minutes the returned hour is the correct hour.
>
> Any ideas ?
>
Yeah, just an idea. Try in crontab

0,30 * * * * sudo { sleep 1; python3 /*****; } (or so)

> Thank you.
>
> Dietmar.

--
Politik ist die Unterhaltungsabteilung der Industrie.
Frank Zappa

Am 18.06.2023 um 14:21 schrieb The Natural Philosopher:
> On 18/06/2023 12:58, Dietmar Mysliwietz wrote:
>> Am 18.06.2023 um 11:22 schrieb R.Wieser:
>>> Dietmar,
>>>
>>> "R.Wieser" <address@is.invalid> wrote in message
>>> news:u6mbsm$1jqm6$1@dont-email.me...
>>> ...
>>>> Provide a bit more info
>>>
>>> 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
>>>
>>>
>>
>> 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).
>>
> 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.
>
>> Now I try timezone information in the Python.
>>
>> Dietmar.
>

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:
> Dietmar Mysliwietz <dmysliwietz@web.de> schrieb:
>> Hallo,
>>
>> I have a python-script which is called at 0 and 30 minutes at every hour
>> from a cronjob:
>>
>> 0,30 * * * * sudo python3 /*****
>>
>> In the script I call the current time:
>>
>> akdatum = datetime.datetime.today()
>> akzeit = akdatum.time()
>> akzeitstr = akzeit.strftime('%H:%M')
>>
>> At 0 minutes the returned hour is one hour BEFORE the real hour.
>> At 30 minutes the returned hour is the correct hour.
>>
>> Any ideas ?
>>
> Yeah, just an idea. Try in crontab
>
> 0,30 * * * * sudo { sleep 1; python3 /*****; } (or so)
>
>
>> Thank you.
>>
>> Dietmar.
>

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:
>
> 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.

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,

> 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.

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.

https://docs.python.org/3.8/library/datetime.html#datetime.timezone

Regards,
Rudy Wieser

Dietmar,

> I don't think that there is a bug in the library.

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

> Where the problem is .. getting crazy

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).

> The date at the commandline returnes the correct time.

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 :

https://stackoverflow.com/questions/13289751/cron-job-in-a-different-timezone

Regards,
Rudy Wieser

On Sun, 18 Jun 2023 18:15:06 +0200
"R.Wieser" <address@is.invalid> wrote:

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

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.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Ahem,

> This has been a standard feature of unix since timezone support
> first appeared.

Thanks for the confirmation.

And it shows how little I actually know about Linux.

> 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.

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:
> Ahem,
>
>> This has been a standard feature of unix since timezone support
>> first appeared.
>
> Thanks for the confirmation.
>
> And it shows how little I actually know about Linux.
>
>> 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.
>
> I already figured that that would be the logic behind having it. :-)
>
> Regards,
> Rudy Wieser
>
>

Thanks again Rudy,

I will tray to figure it out tomorrow.

Thanks a lot to all others.

Have a good night.

Dietmar.

On 18/06/2023 16:04, Dietmar Mysliwietz wrote:
> Am 18.06.2023 um 16:23 schrieb Michael Schütz:
>> Dietmar Mysliwietz <dmysliwietz@web.de> schrieb:
>>> Hallo,
>>>
>>> I have a python-script which is called at 0 and 30 minutes at every hour
>>> from a cronjob:
>>>
>>>      0,30 * * * * sudo python3 /*****
>>>
>>> In the script I call the current time:
>>>
>>>      akdatum    = datetime.datetime.today()
>>>      akzeit     = akdatum.time()
>>>      akzeitstr  = akzeit.strftime('%H:%M')
>>>
>>> At 0 minutes the returned hour is one hour BEFORE the real hour.
>>> At 30 minutes the returned hour is the correct hour.
>>>
>>> Any ideas ?
>>>
>> Yeah, just an idea. Try in crontab
>>
>>     0,30 * * * * sudo { sleep 1; python3 /*****; } (or so)
>>
>>
>>> Thank you.
>>>
>>> Dietmar.
>>
>
> Thank you Michael,
>
> that doesn't help. There was a time delay from 10 seconds in the Python
> at the begin.

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.

Hello Dietmar!

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

> Am 18.06.2023 um 20:10 schrieb R.Wieser:
>> Ahem,
>>
>>> This has been a standard feature of unix since timezone support
>>> first appeared.
>>
>> Thanks for the confirmation.
>>
>> And it shows how little I actually know about Linux.
>>
>>> 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.
>>
>> I already figured that that would be the logic behind having it. :-)
>>
>> Regards,
>> Rudy Wieser
>>
>>

> Thanks again Rudy,

> I will tray to figure it out tomorrow.

> Thanks a lot to all others.

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

On 18/06/2023 17:30, R.Wieser wrote:
> Dietmar,
>
>> I don't think that there is a bug in the library.
>
> Thats a good thought, as problems are seldom caused by bugs. More often its
> just a simple misunderstanding something.
>
Perhaps I code at a different level but I have found several bugs in
PHP and/or javascript implementations.

Right at the edges of what is defined by the language

There is usually a workaround to avoid the case...

--
“The urge to save humanity is almost always only a false face for the
urge to rule it.”
– H. L. Mencken

TNP,

> Perhaps I code at a different level but I have found several bugs in PHP
> and/or javascript implementations.

Not the same languages, but the same here. The most recent one not even a
week old. It doesn't make any difference to my statement.

In practice most "bugs" turn out to be a misunderstanding (of what gets
returned as a result of executing something). Assuming that everything
must be a bug of some sort is therefore quite counter productive.

And I did wonder how you could come up with a "work around" without even
having an idea of what the problem was. Depending on luck perhaps ?
Alas, it didn't work this time. :-)

> Right at the edges of what is defined by the language

Yep. A vague definition leaving it up to the implementer to make sense of
it often does that. Have multiple seperate parties make their own guesses
towards such a vague definition and you're in for a ball.

A prime example of that is how pure HTML webpages (no CSS or JS) display
different in the different browsers (and why some websites still display
"best viewed in ..." banners).

> There is usually a workaround to avoid the case...

There is seldom only one way to solve a problem.

Regards,
Rudy Wieser

On Mon, 19 Jun 2023 11:17:10 +0200
"R.Wieser" <address@is.invalid> wrote:

> A prime example of that is how pure HTML webpages (no CSS or JS) display
> different in the different browsers

That was the original intention with HTML and if the advertisers
who insisted on being able to have pixel for pixel matches to their designs
and been told to get stuffed from the beginning we might have escaped the
chaos of CSS and the difficulties of designing for multiple device types by
just leaving the layout to the browser as originally intended and *only*
providing semantic(ish) markup.

JavaScript seemed like a good idea originally - it has got well out
of hand - DOM interaction was a *BAD* idea.

--
Steve O'Hara-Smith
Odds and Ends at http://www.sohara.org/
Host: Beautiful Theory meet Inconvenient Fact
Obit: Beautiful Theory died today of factual inconsistency

Ahem,

>> A prime example of that is how pure HTML webpages (no CSS or JS) display
>> different in the different browsers

....

> just leaving the layout to the browser as originally intended and *only*
> providing semantic(ish) markup That was the original intention with HTML

Yep.

Though my "different" was aimed at how the different browsers interpret and
"execute" the HTML page, not about formatting HTML as if its a PDF document.

You can still take two different browsers (read: HTML engines) and set their
widths to exactly the same, and you still stand a good chance that a simple
HTML-only document won't look the same on both.

IOW, although the definition of how the different HTML elements are supposed
to behave and is widely available, due to implementation differences the
output differs between browsers.

> JavaScript seemed like a good idea originally - it has got well out
> of hand - DOM interaction was a *BAD* idea.

It was. Just as atomic energy was. But alas, there are always people who
weaponise stuff like that.

Personally I've got JS permanently disabled. Because I've been taught that
running programs from unknown sources is never a good idea.

Ofcourse, knowing that most JS is used for advertisements doesn't really
help either. :-)

Regards,
Rudy Wieser

"Ahem A Rivet's Shot" <steveo@eircom.net> wrote in message
news:20230619114251.e11e36440d6ee36f6cb06d70@eircom.net...
> On Mon, 19 Jun 2023 11:17:10 +0200
> "R.Wieser" <address@is.invalid> wrote:
>
>> A prime example of that is how pure HTML webpages (no CSS or JS) display
>> different in the different browsers
>
> That was the original intention with HTML and if the advertisers
> who insisted on being able to have pixel for pixel matches to their
> designs
> and been told to get stuffed from the beginning we might have escaped the
> chaos of CSS and the difficulties of designing for multiple device types
> by
> just leaving the layout to the browser as originally intended and *only*
> providing semantic(ish) markup.
>
> JavaScript seemed like a good idea originally - it has got well out
> of hand - DOM interaction was a *BAD* idea.
>
> --
> Steve O'Hara-Smith
> Odds and Ends at http://www.sohara.org/
> Host: Beautiful Theory meet Inconvenient Fact
> Obit: Beautiful Theory died today of factual inconsistency

On 18/06/2023 16:00, Dietmar Mysliwietz wrote:
> Am 18.06.2023 um 14:21 schrieb The Natural Philosopher:
>> On 18/06/2023 12:58, Dietmar Mysliwietz wrote:
>>> Am 18.06.2023 um 11:22 schrieb R.Wieser:
>>>> Dietmar,
>>>>
>>>> "R.Wieser" <address@is.invalid> wrote in message
>>>> news:u6mbsm$1jqm6$1@dont-email.me...
>>>> ...
>>>>> Provide a bit more info
>>>>
>>>> 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
>>>>
>>>>
>>>
>>> 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).
>>>
>> 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.
>>
>>> Now I try timezone information in the Python.
>>>
>>> Dietmar.
>>
>
> 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.

I had a quick look and couldn't see where, or how, the value of
datetime.today() becomes aware of timezone. There is some twaddle about
"aware" and "naive" but I lost the will to live after seeing
"unambiguously".

As far as I can see, the only safe thing to do is to explicitly set the
datetime tzinfo attribute. All in all, it looks like poo, not uncommon
for datetime libraries.