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
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 v22.214.171.124, 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
- 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