On 7/30/21 7:13 PM, clipka wrote:
> Am 30.07.2021 um 23:38 schrieb Cousin Ricky:
> 
>>> I realize only now that I accidently implemented the wrong behavior
>>> (judging by the documentation, and intent so far).
>>
>> The 3.8 documentation say 'now' should return GMT, and on my GNU/Linux

>> in behavior?
> 
> I think I do, yes.
> 
> The current behavior appears to be quite inconsistent across platforms 
> and systems and whatnot.

Cousin Ricky is onto something; Me screwing up with respect to v3.8 beta 
1 results. :-(

I maintain "many" versions of POV-Ray which I run with wrapper scripts 
that are careful to strip any $HOME directory or environment variable 
customizations - so I'm always testing the native code and set up.

When I grabbed and compiled:
https://github.com/POV-Ray/povray/releases/tag/v3.8.0-beta.1

I created a 'p380b1' wrapper script, but I screwed up and pointed it to 
the v3.8 compile directories for the commit from off of which I'm basing 
my povr stuff. All my testing of v3.8 beta 1 over the last couple weeks 
has been against something closer to the current master branch. 
#@%^$^%$&!!! The version is clearly there in the text output, which I 
ignore 99.99% of the time...

What this means is the 'now' command I was running as v3.8 beta 1 was 
the newer(1) c++11 version. It's that one not returning the utc/gmt/zulu 
time making the default 'Z' format suffix wrong.

(1) - Though I've been running primarily that one for years - so I was 
seeing what I expected to see as datetime(now) output.

---
I think, Christoph, an option - if you want to minimize v3.8 release 
change - would be to let things go as they are. This would mean a hard 
UTC datetime() result without working %z and %Z format options (others?).

I agree with your thinking the behavior of 'now' should updated, but 
this could be delayed to v4.0.

Bill P.

Post a reply to this message