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.

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

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

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

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

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.

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

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

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.

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!

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!

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.

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.

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.

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

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

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.

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

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.

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