Am 11.08.2021 um 13:08 schrieb clipka:

> regarding the `datetime(now)` issue, I need more information from you 
> folks, to make sure I'm not hunting a phantom.

The data I've gotten so far supports my suspicion, so I'd like to take 
this call to arms into a different mode of operation.

Anyone who hasn't replied so far, but wants to assist in this, I'd just 
like you to confirm that the following holds for your system, too:

--
When using either POV-Ray v3.7 or v3.8.0-beta.1 (sic! I don't care about 
beta.2 in this context), `datetime(now)` returns a string that matches 
the current time as UTC (frequently referred to as "GMT", and being 
equal to London local time when DST is not in effect), with a trailing 
literal "Z" (which "happens" to be the ISO timezone code for UTC).

(please specify operating system, POV-Ray version and timezone when 
replying.)
--

Unless someone reports otherwise, my preliminary verdict is as follows:

- There never was a bug in the first place (well, not this one anyway) 
that would show on some _systems_ and not on others. Instead, there was 
a bug that would show on some _versions_ of POV-Ray and not on others.

- `datetime()` and `now` had always been working exactly as intended and 
documented, starting with its introduction in v3.7.0.0, until...

- it was actually borked by me in v3.8.0-alpha.10064268 when I rewrote 
the code to use C++11 features instead of boost, to no longer require 
the boost datetime library.

- The new code would instead have `now` report time since 2000-01-01 
00:00 local time, instead of UTC, while `datetime` would continue to 
expect UTC and thus printed a wrong time (and still explicitly claiming 
it to be UTC). That time would happen to match local time, but only when 
DST was not in effect (in the northern hemisphere; in the southern 
hemisphere, the behavior regarding DST would presumably be the other way 
round).

- With the rollback to earlier v3.8.0 code, we also switched back to the 
properly working `now` code, so the bug was already absent again in 
v3.8.0-beta.1; and my attempt to fix it in v3.8.0-beta.2 presumably did 
nothing at all, except waste time (both mine in developing it and yours 
in rendering scenes making use of `now`, which take a tiny bit longer to 
parse with the "fix").


Crucially, this means that the borked behavior hasn't been around very 
long (comparatively), so there isn't really much pressure to do anything 
at all in the name of backward compatibility.

It also means that I can be reasonably sure that a solution which works 
on my Windows machine will also work on your Lunix machines.


What's still left for me to do is:

* Investigate that other (probably entirely unrelated) problem regarding 
DST when using a non-default format string in `datetime`, specifically 
when using `%z` or `%Z` to display local timezone information.

* For convenience, provide a means for users to actually get a local 
date out of `datetime` (and one that respects DST, for that matter).

Post a reply to this message