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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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"

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- Mageia Linux v8 X64/Mbse v1.0.8.3/GoldED+/LNX 1.1.5-b20180707
* Origin: Air Applewood, The Linux Gateway to the UK & Eire (2:250/1)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

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.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 18/06/2023 16:00, Dietmar Mysliwietz wrote:

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.

Caveat, I'm not a python programmer.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 14:23, Pancho wrote:

On 18/06/2023 16:00, Dietmar Mysliwietz wrote:

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.

Caveat, I'm not a python programmer.

So following your example (I use utc, you can use whatever you like)


akziet = datetime.datetime.now(datetime.timezone.utc)
akzeitstr = akdatum.strftime('%H:%M %Z')

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 14:39, Pancho wrote:

On 19/06/2023 14:23, Pancho wrote:

On 18/06/2023 16:00, Dietmar Mysliwietz wrote:

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.

Caveat, I'm not a python programmer.

So following your example (I use utc, you can use whatever you like)

akziet    = datetime.datetime.now(datetime.timezone.utc)
akzeitstr  = akdatum.strftime('%H:%M %Z')

Or even

akziet = datetime.datetime.now(datetime.timezone.utc)
akzeitstr = akziet.strftime('%H:%M %Z')

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 19 Jun 2023 14:23:45 +0100
Pancho <Pancho.Jones@proton.me> wrote:

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.

If you don't set it explicitly then python will pick up a default
which can come from the TZ environment variable or if that is not set then
it should be the system default timezone. This applies to all date related functions not just python datetime viz:

✓ steve@steve ~ $ TZ=GMT date
Mon 19 Jun 2023 13:53:52 GMT
✓ steve@steve ~ $ TZ="Europe/Paris" date
Mon 19 Jun 2023 15:54:11 CEST
✓ steve@steve ~ $ date
Mon 19 Jun 2023 14:54:50 IST

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 19 Jun 2023 14:35:12 +0200
"R.Wieser" <address@is.invalid> wrote:

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.

Of course HTML does not define what the appearance (if any) of the rendered output looks like. It is entirely up to the browser what fonts,
sizes, colours etc. are used (if any - support for all of the appearance attributes is optional) - that way there are no constraints on the
capability of the browser and/or display so for example it should be
perfectly possible and valid to render a pure HTML page in braille without semantic loss.

The first HTML browsers did not render images inline (they
optionally downloaded them) and worked just fine on an 80x25 (or any other available size) monochrome terminal. Mosaic may have been the first mistake
of the WWW!

Netscape 2.0 which introduced file upload and JavaScript really set
the ball rolling - and introduced the first security horror, you could put
a hidden file upload field in a form, fill it with JavaScript
(say /etc/master.passwd) and submit the form with JavaScript to collect arbitrary files from systems.

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

There is much to be said for this approach - my own browser is set
up that way but for work there are too many cases where the browser is
mostly a UI server for applications - a perfectly valid and useful thing in itself but it's a shame that it wound up incorporated into the web browser.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 14:55, Ahem A Rivet's Shot wrote:

On Mon, 19 Jun 2023 14:23:45 +0100
Pancho <Pancho.Jones@proton.me> wrote:

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.

If you don't set it explicitly then python will pick up a default
which can come from the TZ environment variable or if that is not set then
it should be the system default timezone. This applies to all date related functions not just python datetime viz:

✓ steve@steve ~ $ TZ=GMT date
Mon 19 Jun 2023 13:53:52 GMT
✓ steve@steve ~ $ TZ="Europe/Paris" date
Mon 19 Jun 2023 15:54:11 CEST
✓ steve@steve ~ $ date
Mon 19 Jun 2023 14:54:50 IST

Channelling Victor Meldrew : I don't believe you.

The evidence of running, the following on rpi4/ubuntu:


----

print( datetime.datetime.today().time().strftime('%H:%M %Z') )

15:16
----

----

print( datetime.datetime.now().strftime('%H:%M %Z') )

15:16
----

----

print( datetime.datetime.now(datetime.timezone.utc).strftime('%H:%M

%Z') )
14:19 UTC
----

Yes, the first two are in my localtime, BST, but Python is giving it as
a “naive” time, it isn't using a timezone. The third one does is recognizing timezone.

As an experienced programmer, I wouldn't touch a “naive” datetime with a bargepole.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Mon, 19 Jun 2023 15:27:16 +0100
Pancho <Pancho.Jones@proton.me> wrote:

Yes, the first two are in my localtime, BST, but Python is giving it as
a “naive” time, it isn't using a timezone. The third one does is recognizing timezone.

Python naive time certainly does use a timezone - it uses the best guess it can get for the local timezone which is derived as I described viz:

✗ steve@steve ~ $ python3
Python 3.9.16 (main, Apr 2 2023, 01:13:51)
[Clang 13.0.0 (git@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a on freebsd13 Type "help", "copyright",
"credits" or "license" for more information.

import datetime
print( datetime.datetime.now().strftime('%H:%M %Z') )

17:15

✓ steve@steve ~ $ TZ="America/Los_Angeles" python3
Python 3.9.16 (main, Apr 2 2023, 01:13:51)
[Clang 13.0.0 (git@github.com:llvm/llvm-project.git
llvmorg-13.0.0-0-gd7b669b3a on freebsd13 Type "help", "copyright",
"credits" or "license" for more information.

import datetime
print( datetime.datetime.now().strftime('%H:%M %Z') )

09:15

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Ahem,

Of course HTML does not define what the appearance (if any) of
the rendered output looks like.

I think I disagree with you there - although you are pretty-much making my point for me here : by not having a strict definitions or having ones that
lack in clarity the end result from the different implementers differs.
Which could easily be the "fringe cases" TNP was referring to as "bugs".

Or, said simpler : those "fringe cases" probably work without any problem within the browser it was created for, but its output could mismatch that of another browser.

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

There is much to be said for this approach - my own browser is set
up that way but for work there are too many cases where the browser is
mostly a UI server for applications - a perfectly valid and useful thing
in
itself but it's a shame that it wound up incorporated into the web
browser.

I do not really consider scripting in a browser a problem per se - I'm using GreaseMonkey to alter webpages to my liking, which uses JS to do its thing -
as long as *I* decide which script is downloaded (or not) and from where.
And the "from where" should include "from local storage". That way those scripts can be downloaded before actual usage and veto-ed by either the user himself, or downloaded from a trusted source.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 10:17, R.Wieser wrote:

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

No, careful analysis and experience of low level programming.

Example : uploading a file using PHP/webserver. It works. But if you
upload the file, them use the filename as an argument to a mysql routine designed to put that file in as databasse, it does not work.

Reason? The file is not actually written to the disk subsystem until PHP
exits and flushes its buffers.

Hack: copy the file in php to a new file location, and delete the
original. For some reason the copy command DOES t write to the disk
subsystem.
Example. IE 6 and firefox had different rules for evaluation when e.g a
1 was a number and when it was a string. In JavaScript.
Normally the rule is that if you are using the result in a string, its a string, if the result is going into a numeric variable its a number.
But what if its being used in a conditional expression? And what it is
being compared to is not well defined type wise.?

All bets are off, and that is the trouble with these clever untyped
languages. In C 1 is a number and "1" is a string and that's that.

If (1=="1")
{you have a compiler bug!}

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.

IE Edge Firefox Chrome & Safari cant even agree on a basic page.
And if you start to shrink a page down many browsers will have 'a font
below which you told me not to go'

Adavanced JavaScript often works perfectly on one browser and not at all
on another.

Regards,
Rudy Wieser

--
There is nothing a fleet of dispatchable nuclear power plants cannot do
that cannot be done worse and more expensively and with higher carbon
emissions and more adverse environmental impact by adding intermittent renewable energy.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 11:42, Ahem A Rivet's Shot wrote:

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.

No, it was a great *idea* - if everybody had agreed on the same way to
do it.
If I couldn't do it I wouldn't be using javascript AT ALL.


--
Any fool can believe in principles - and most of them do!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 20:36, R.Wieser wrote:

Which could easily be the "fringe cases" TNP was referring to as "bugs".

Or, said simpler : those "fringe cases" probably work without any problem within the browser it was created for, but its output could mismatch that of another browser.

Not quite. What irritates me is fairly simple things that do not work as
the documentation says they should, or work differently in two
implementations of the same language.

As I said I think the simple case in Javascriot boiled down to

if('1'=="1") or something like that - its ten years ago now.
It was a casting issue where the rueles of the language had not exactly
been specified for that case.

In the case of PHP it boiled down to 'when do you expect a file written
by PHP to be available to an external program (mysqld daemon)'


Now these are what I call bugs, in the the programmer hasn't actually
thought the issue might occur, and so has made no specific provision
for it, so the answer becomes 'implementation dependent' I call that a
bug. If clear data in produces indeterminate output, that is not clean code


--
Karl Marx said religion is the opium of the people.
But Marxism is the crack cocaine.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 14:40, Pancho wrote:

On 19/06/2023 14:39, Pancho wrote:

On 19/06/2023 14:23, Pancho wrote:

On 18/06/2023 16:00, Dietmar Mysliwietz wrote:

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.

Caveat, I'm not a python programmer.

So following your example (I use utc, you can use whatever you like)


akziet    = datetime.datetime.now(datetime.timezone.utc)
akzeitstr  = akdatum.strftime('%H:%M %Z')

Or even

akziet    = datetime.datetime.now(datetime.timezone.utc)
akzeitstr  = akziet.strftime('%H:%M %Z')

This timezome shit is a red herring because it works for half past the hour

--
Any fool can believe in principles - and most of them do!

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 17:16, Ahem A Rivet's Shot wrote:

On Mon, 19 Jun 2023 15:27:16 +0100
Pancho <Pancho.Jones@proton.me> wrote:

Yes, the first two are in my localtime, BST, but Python is giving it as
a “naive” time, it isn't using a timezone. The third one does is
recognizing timezone.

Python naive time certainly does use a timezone - it uses the best guess it can get for the local timezone which is derived as I described viz:

No it doesn't. As I showed, now() is not associating a timezone with
datetime objects, it could, but it doesn't.

After a bit of reading, I see that it is possible to code using the
assumption that Naive python dates are UTC, and hence need no timezone.
Which is how I would handle a datetime type. Using the standard
technique of handling timezones only for conversion of dates to/from
other formats. e.g. a string formatter for output, or a factory method.

But looking at the documentation it is vastly more complicated than it
needs to be, and in coding terms it is an accident waiting to happen.
Sometimes they do associate a datetime object with a timezone, sometimes
they don't. This allows programmers to assume different paradigms.
Nasty, confusing.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 19/06/2023 23:29, The Natural Philosopher wrote:

Or even

akziet    = datetime.datetime.now(datetime.timezone.utc)
akzeitstr  = akziet.strftime('%H:%M %Z')

This timezome shit is a red herring because it works for half past the hour

Wouldn't hurt to explicitly set it, and print it out. Rule out the
possibility. Just to make a silly old man happy.

I would also show the minutes.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 20 Jun 2023 10:03:53 +0100
Pancho <Pancho.Jones@proton.me> wrote:

On 19/06/2023 17:16, Ahem A Rivet's Shot wrote:

On Mon, 19 Jun 2023 15:27:16 +0100
Pancho <Pancho.Jones@proton.me> wrote:

Yes, the first two are in my localtime, BST, but Python is giving it as
a “naive” time, it isn't using a timezone. The third one does is
recognizing timezone.

Python naive time certainly does use a timezone - it uses the
best guess it can get for the local timezone which is derived as I described viz:

No it doesn't. As I showed, now() is not associating a timezone with
datetime objects, it could, but it doesn't.

Conversion of the unix clock (a counter of seconds since the epoch) into a human readable date and time *always* uses a timezone it is
impossible for it not to.

In the example you snipped I demonstrated that datetime.now() is sensitive to the TZ environment variable just like date. This all stems
from the low level C standard library functions which establish a default timezone based on a system default, overridden by TZ, overridden by
parameters.

After a bit of reading, I see that it is possible to code using the assumption that Naive python dates are UTC, and hence need no timezone.

In my first example that assumption would fail because the default timezone in my environment is Ireland/Dublin which is subject to DST and is currently one hour ahead of UTC but in a few months time will match UTC.

You can of course *force* python datetime (and pretty much
anything else) to use UTC by having TZ=UTC in the environment.

There's nothing magical about datetime it's just a wrapper over the
C standard library functions which is why it behaves exactly the same as
the date command in every test I have ever made.

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

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

Am 18.06.2023 um 22:26 schrieb NY:

On 18/06/2023 16:04, Dietmar Mysliwietz wrote:

Hi, back again,

thanks for all your help for timezones and all this stuff.

My raspi was configured to Europe/Berlin. And I've got this info too:

pi@raspberrypi:~ $ timedatectl
Local time: Mon 2023-06-19 11:08:32 CEST
Universal time: Mon 2023-06-19 09:08:32 UTC
RTC time: n/a
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no

After a lot of this and that I found out, the problem was not a timezone.

It was a problem with socat which is used to transfer serial data in a file
and is called every 0-minute to read the data out of the file. Why my
script doesn't work anymore last week after years - I don't know.

So all the discussion here was not really a help for my problem, but
helpful for timezones for me as a non linux-expert.

With greetings,

Dietmar

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 6/20/23 11:07, Ahem A Rivet's Shot wrote:

On Tue, 20 Jun 2023 10:03:53 +0100
Pancho <Pancho.Jones@proton.me> wrote:

On 19/06/2023 17:16, Ahem A Rivet's Shot wrote:

On Mon, 19 Jun 2023 15:27:16 +0100
Pancho <Pancho.Jones@proton.me> wrote:

Yes, the first two are in my localtime, BST, but Python is giving it as >>>> a “naive” time, it isn't using a timezone. The third one does is
recognizing timezone.

Python naive time certainly does use a timezone - it uses the
best guess it can get for the local timezone which is derived as I
described viz:

No it doesn't. As I showed, now() is not associating a timezone with
datetime objects, it could, but it doesn't.

Conversion of the unix clock (a counter of seconds since the epoch) into a human readable date and time *always* uses a timezone it is
impossible for it not to.

Not really, you can calculate the years, days, minutes etc, add them to
Jan 1 1970 00:00:00.000000. There is no need for any timezone. It is
universal time. That is kind of the point of UTC. That is why seconds
from epoch time is a good date representation.

In the example you snipped I demonstrated that datetime.now() is sensitive to the TZ environment variable just like date. This all stems
from the low level C standard library functions which establish a default timezone based on a system default, overridden by TZ, overridden by parameters.

You have missed the point. The Python datatype follows a human readable
format: year, month, day, hour, minute, second, microsecond, tzinfo.

You are telling me datetime.now() populates, year, month, day,...
appropriately for the current unix time and value of TZ. I'm telling
you, it does not populate tzinfo. That is, it creates a python naive
date. A datetime only valid in the context of the current timezone.

The value this datetime object holds is ambiguous, dependent upon how a programmer interprets it.

After a bit of reading, I see that it is possible to code using the
assumption that Naive python dates are UTC, and hence need no timezone.

In my first example that assumption would fail because the default timezone in my environment is Ireland/Dublin which is subject to DST and is currently one hour ahead of UTC but in a few months time will match UTC.

One can use appropriate, factory objects, conversion methods, string formatters. The difficulty is that it is a programming convention, a
coding style. A programmer unfamiliar with the convention can mess up.
They can create a naive datetime that is a local time when it should be
a UTC value. Or they can misinterpret datetimes from different
timezones. They can use now() which implicitly uses a timezone, but
doesn't record that it has done so.

I think this is what utcnow() is for, this convention where naive
datetimes are UTC.

You can of course *force* python datetime (and pretty much
anything else) to use UTC by having TZ=UTC in the environment.

There's nothing magical about datetime it's just a wrapper over the
C standard library functions which is why it behaves exactly the same as
the date command in every test I have ever made.

I don't know what C standard library date functions are, but python
datetime is more than a wrapper, maybe it is a conceptual copy of the C implementation

I've never worked with a company that didn't have its own datetime library.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On 6/20/23 23:23, Martin Gregorie wrote:

On Tue, 20 Jun 2023 22:17:54 +0100, Pancho wrote:

I don't know what C standard library date functions are, but python
datetime is more than a wrapper, maybe it is a conceptual copy of the C
implementation

I've never worked with a company that didn't have its own datetime

library.

Interesting: My experience is the exact opposite: The first part of my working life was spent writing COBOL where you have little choice in
getting hlold of the date and.or time: ACCEPTing them from the OS returned DDMMYY until CODASYL eventually got round to adding two more digits for
the century.

Apart from that, I mostly wrote ANSI C and we never saw any reason to use anything other than the standard C library date&time functions regardless
of what countries the code would be running in.

Banking/finance apps are highly dependent on holiday calendars and day
count conventions.

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 20 Jun 2023 23:44:18 +0100, Pancho wrote:

Banking/finance apps are highly dependent on holiday calendars and day
count conventions.

Indeed they are: been there, done that and multi-currency systems that are
also networked across time zones and national borders are
'interesting' (ever looked into predicting the length of future years in
the Islamic calendar (you can't!). However I was more concerned with the
sorts of financial networks that run on fault tolerant systems and with
ATM networks than with financial institution's internal systems.


--

Martin | martin at
Gregorie | gregorie dot org

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)

On Tue, 20 Jun 2023 22:17:54 +0100, Pancho wrote:

I don't know what C standard library date functions are, but python
datetime is more than a wrapper, maybe it is a conceptual copy of the C implementation

I've never worked with a company that didn't have its own datetime

library.

Interesting: My experience is the exact opposite: The first part of my
working life was spent writing COBOL where you have little choice in
getting hlold of the date and.or time: ACCEPTing them from the OS returned DDMMYY until CODASYL eventually got round to adding two more digits for
the century.

Apart from that, I mostly wrote ANSI C and we never saw any reason to use anything other than the standard C library date&time functions regardless
of what countries the code would be running in.

--

Martin | martin at
Gregorie | gregorie dot org

--- SoupGate-Win32 v1.05
* Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)