• Time shift

    From Dietmar Mysliwietz@3:770/3 to All on Sat Jun 17 16:53:23 2023
    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)
  • From Lew Pitcher@3:770/3 to Dietmar Mysliwietz on Sat Jun 17 16:13:24 2023
    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)
  • From David Taylor@3:770/3 to Dietmar Mysliwietz on Sat Jun 17 18:58:06 2023
    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

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From R.Wieser@3:770/3 to All on Sun Jun 18 09:31:24 2023
    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)
  • From R.Wieser@3:770/3 to R.Wieser on Sun Jun 18 11:22:13 2023
    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)
  • From Martin Gregorie@3:770/3 to Dietmar Mysliwietz on Sun Jun 18 11:51:16 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Sun Jun 18 13:51:57 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Sun Jun 18 13:58:43 2023
    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)
  • From The Natural Philosopher@3:770/3 to Dietmar Mysliwietz on Sun Jun 18 13:21:19 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Sun Jun 18 17:00:32 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Sun Jun 18 17:04:16 2023
    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)
  • From Michael =?UTF-8?Q?Sch=C3=BCtz?=@3:770/3 to Dietmar Mysliwietz on Sun Jun 18 16:23:28 2023
    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)
  • From R.Wieser@3:770/3 to All on Sun Jun 18 18:15:06 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Sun Jun 18 17:28:47 2023
    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)
  • From R.Wieser@3:770/3 to All on Sun Jun 18 18:30:45 2023
    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)
  • From Ahem A Rivet's Shot@3:770/3 to R.Wieser on Sun Jun 18 17:33:50 2023
    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)
  • From R.Wieser@3:770/3 to All on Sun Jun 18 20:10:48 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Sun Jun 18 21:52:45 2023
    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.

    --- SoupGate-Win32 v1.05
    * Origin: Agency HUB, Dunedin - New Zealand | Fido<>Usenet Gateway (3:770/3)
  • From NY@3:770/3 to Dietmar Mysliwietz on Sun Jun 18 21:26:55 2023
    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)
  • From Vincent Coen@2:250/1 to Dietmar Mysliwietz on Sun Jun 18 22:48:06 2023
    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)
  • From The Natural Philosopher@3:770/3 to R.Wieser on Mon Jun 19 08:58:02 2023
    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)
  • From R.Wieser@3:770/3 to All on Mon Jun 19 11:17:10 2023
    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)
  • From Ahem A Rivet's Shot@3:770/3 to R.Wieser on Mon Jun 19 11:42:51 2023
    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)
  • From R.Wieser@3:770/3 to All on Mon Jun 19 14:35:12 2023
    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)
  • From Pancho@3:770/3 to Dietmar Mysliwietz on Mon Jun 19 14:22:08 2023
    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)
  • From Pancho@3:770/3 to Dietmar Mysliwietz on Mon Jun 19 14:23:45 2023
    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)
  • From Pancho@3:770/3 to Pancho on Mon Jun 19 14:39:11 2023
    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)
  • From Pancho@3:770/3 to Pancho on Mon Jun 19 14:40:58 2023
    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)
  • From Ahem A Rivet's Shot@3:770/3 to Pancho on Mon Jun 19 14:55:29 2023
    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)
  • From Ahem A Rivet's Shot@3:770/3 to R.Wieser on Mon Jun 19 14:46:01 2023
    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)
  • From Pancho@3:770/3 to Ahem A Rivet's Shot on Mon Jun 19 15:27:16 2023
    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)
  • From Ahem A Rivet's Shot@3:770/3 to Pancho on Mon Jun 19 17:16:13 2023
    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)
  • From R.Wieser@3:770/3 to All on Mon Jun 19 21:36:49 2023
    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)
  • From The Natural Philosopher@3:770/3 to R.Wieser on Mon Jun 19 23:26:35 2023
    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)
  • From The Natural Philosopher@3:770/3 to Ahem A Rivet's Shot on Mon Jun 19 23:28:09 2023
    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)
  • From The Natural Philosopher@3:770/3 to R.Wieser on Mon Jun 19 23:39:47 2023
    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)
  • From The Natural Philosopher@3:770/3 to Pancho on Mon Jun 19 23:29:36 2023
    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)
  • From Pancho@3:770/3 to Ahem A Rivet's Shot on Tue Jun 20 10:03:53 2023
    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)
  • From Pancho@3:770/3 to The Natural Philosopher on Tue Jun 20 09:53:08 2023
    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)
  • From Ahem A Rivet's Shot@3:770/3 to Pancho on Tue Jun 20 11:07:03 2023
    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)
  • From Dietmar Mysliwietz@3:770/3 to All on Tue Jun 20 18:15:53 2023
    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)
  • From Pancho@3:770/3 to Ahem A Rivet's Shot on Tue Jun 20 22:17:54 2023
    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)
  • From Pancho@3:770/3 to Martin Gregorie on Tue Jun 20 23:44:18 2023
    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)
  • From Martin Gregorie@3:770/3 to Pancho on Tue Jun 20 23:02:47 2023
    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)
  • From Martin Gregorie@3:770/3 to Pancho on Tue Jun 20 22:23:58 2023
    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)