Time shift

TNP,

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

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 seldom only one way to solve a problem.

Regards, Rudy Wieser

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.

Ahem,

...

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.

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

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.

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

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.

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.

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

----

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

----

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

----

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.

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 ( snipped-for-privacy@github.com:llvm/llvm-project.git llvmorg-13.0.0-0-gd7b669b3a on freebsd13 Type "help", "copyright", "credits" or "license" for more information.

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

Ahem,

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.

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

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

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

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.

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.

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

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

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.

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.

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.

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.