Am 29.07.2021 um 13:45 schrieb William F Pokorny:

> Supposing the SDL:
> 


> 
> And the 'date' command on my Ubuntu 20.04 computer returning:
> 

> 
> The v3.8 branch returns:
> 


> 
> The povr branch returns:
> 


> 
> Bill P.

Oh hooray.

So, after some digging, it turns out that on Linux machines, 
`boost::posix_time::microsec_clock::universal_time()` does specifically 
*NOT* do what it was designed to do (at least with the boost version 
we're bundling for Windows builds).

> (*) The -100000 days is somewhat arbitrary. Just needs to be earlier 
> than the unix epoch time to trigger the dst aware mode.

I have no idea what you're saying there. What do you need to trigger, 
and why?

Post a reply to this message

Can someone test whether the fix in this pull request actually solves 
the time zone issue?

https://github.com/POV-Ray/povray/pull/433

It should cause `datetime(now)` to print UTC (as opposed to local) time, 
while still incrementing significantly faster than once per second.


What I'm doing there is query another timer to get a second opinion. 
While that timer is of lower precision (seconds instead of 
microseconds), it should reliably give proper UTC. So by using that as a 
reference, we can adjust the high-precision timer accordingly by a 
multiple of 15 minutes, to give us high-precision UTC.

Post a reply to this message

On 7/29/21 5:43 PM, clipka wrote:
> Can someone test whether the fix in this pull request actually solves 
> the time zone issue?
> 
> https://github.com/POV-Ray/povray/pull/433
> 
> It should cause `datetime(now)` to print UTC (as opposed to local) time, 
> while still incrementing significantly faster than once per second.
> 
> 
> What I'm doing there is query another timer to get a second opinion. 
> While that timer is of lower precision (seconds instead of 
> microseconds), it should reliably give proper UTC. So by using that as a 
> reference, we can adjust the high-precision timer accordingly by a 
> multiple of 15 minutes, to give us high-precision UTC.

First, what the -1e5 argument to datetime() does in the povr branch is 
flip to code inside Parser::Parse_Datetime which uses std::time(nullptr) 
over the argument - POV-Ray's 'now' is not relevant.

---
In my testing your fix gives me the utc time as a hard coded result - 
and it's the only datetime string I can get with 'now'.

2021-07-30 12:48:35Z

What about local datetime strings with %z or %Z? The secondary issue I'd 
forgotten I hit back in June with the boost code is that:

std::tm t = 
boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));

doesn't set up the %Z and %z capability. Using both in the string format 
option gives me: "2021-07-30 12:48:35".

One can set up those fields by calling strftime() with an argument of:
std::localtime(&t), here getting EDT/-0400, but the date and time string 
is still strictly UTC - so it's not particularly useful except maybe to 
work backward to the actual time zone date and time in a uncommon / 
awkward way and to do that you'd need to know the data/time was UTC no 
matter the EDT or -0400 in the returned string.

---
I guess I see a place for a hard coded 'now' UTC/Z result - and as 
accurate an internal time/timer as we can get (is your fix at odds with 
timer use?). I don't see it as what most people will want with 
datetime(). This why I coded up a more traditional std::time(nullptr) as 
an optional mode of datetime()(a).

Aside 1: A reminder that in newer(to be v4.0) code, you moved 'now' off 
boost completely. This is in fact is the code povr uses - meaning any 
unix/linux 'bug' is in that code too.

Aside 2: The Parse_Datetime() code has too that use of:

setlocale(LC_TIME,"");

the full implications of which made me a little nervous along with the 
etting being afterward persistent. So after the strftime() call I added:

setlocale(LC_TIME,"C");

to return the setting to the C++ start up default. In a scan of the code 
I didn't pick up any other adjustments to the default locale.

Bill P.

(a) Lying some. Unsure what might happen with the boost variant over the 
pure c++11 one for now, but the latter didn't account for daylight 
savings adjustments which also makes datetime(), %z and %Z less than 
precisely useful.

Post a reply to this message

Am 30.07.2021 um 16:00 schrieb William F Pokorny:

> In my testing your fix gives me the utc time as a hard coded result - 
> and it's the only datetime string I can get with 'now'.
> 
> 2021-07-30 12:48:35Z
> 
> What about local datetime strings with %z or %Z? The secondary issue I'd 
> forgotten I hit back in June with the boost code is that:
> 
> std::tm t = 
> boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));
> 
> doesn't set up the %Z and %z capability. Using both in the string format 
> option gives me: "2021-07-30 12:48:35".
> 
> One can set up those fields by calling strftime() with an argument of:
> std::localtime(&t), here getting EDT/-0400, but the date and time string 
> is still strictly UTC - so it's not particularly useful except maybe to 
> work backward to the actual time zone date and time in a uncommon / 
> awkward way and to do that you'd need to know the data/time was UTC no 
> matter the EDT or -0400 in the returned string.

That would require making `now` a more complicated beast than just a 
numeric value, as we can't transport timezone information in that format.

I'm not going there. Not in v3.8, at any rate. Nor am I going the povr 
route of hacking something into `datetime` to make it look up the 
current time on its own when it gets passed some magic value. Retrieving 
the current time is precisely the job of `now`.


As it currently stands, we have no sane way (in v3.8) of achieving all 
the following ideal goals:

- Have separate mechanisms to get the current point in time (`now`), and 
print a point in time (`datetime`).

- Have a simple "phrase" (combo of the above) to automatically print the 
given point in time as UTC, without extra effort, and in a way that it 
won't be mistaken for local time.

- Have a simple "phrase" (combo of the above) to automatically print the 
given point in time as local time, without extra effort, and in a way 
that it won't be mistaken for UTC.


I think the following arguments lead to the sanest solution:

- If we have `datetime` default to a string that explicitly prints any 
time zone information (as we currently do), then for the default to be 
not blatantly wrong, we limit ourselves to one "flavor" of point-in-time 
information: Either local ("%z" suffix), or UTC ("Z" suffix). If on the 
other hand we omit the time zone entirely from the default, the output 
will, for both flavors, be at least not entirely wrong.

This speaks heavily in favor of not including any time zone suffix at 
all by default, i.e. dropping the "Z" we're currently appending.

- When users see a date or time, they will usually expect it to indicate 
local time. To achieve that, the parameter passed to `datetime()` would 
have to be of local time flavor.

This speaks heavily in favor of making `now` return local time, as 
opposed to UTC.


I think it can be argued that local time is of far more relevance to 
most users than UTC.

Should someone come up with any use case that needs access to the 
current time in UTC, then possible workarounds would be:

- for the user to hard-code time zone offset into their scene file;

- for the user to design the scene such that time zone offset can be 
passed via `Declare=` INI file setting;

- for us to provide some `timezone` pre-defined variable that evaluates 
to the time zone offset in days, ready to be subtracted from `now` to 
give UTC, or a `utc()` function that converts from local time to UTC. (I 
would lean towards the latter, as the former variable would not be in 
the common format of hours, which might give rise to confusion.)


> I guess I see a place for a hard coded 'now' UTC/Z result - and as 
> accurate an internal time/timer as we can get (is your fix at odds with 
> timer use?).

I'm not sure what you mean by "at odds with timer use".

What I can say is that the fix does not compromise timer precision, if 
that's what you mean.


> Aside 1: A reminder that in newer(to be v4.0) code, you moved 'now' off 
> boost completely. This is in fact is the code povr uses - meaning any 
> unix/linux 'bug' is in that code too.

Actually, no - in this case `now` returning local time is not a 
Unix/Linux bug (or, more to the point, not a "boost on Unix/Linux bug"), 
but rather proper intrinsic behavior of the new implementation I chose.

I realize only now that I accidently implemented the wrong behavior 
(judging by the documentation, and intent so far).

It's not the worst of accidents though. I'd like to consider it a Bob 
Ross moment.


> Aside 2: The Parse_Datetime() code has too that use of:
> 
> setlocale(LC_TIME,"");
> 
> the full implications of which made me a little nervous along with the 
> etting being afterward persistent.

You and me both, bro.

> So after the strftime() call I added:
> 
> setlocale(LC_TIME,"C");

Without any additional safety net, that would actually be 
counter-productive: `setlocale` is not thread-safe; so if we ever run 
multiple parser threads in parallel, and they come across the same piece 
of code nearly at the same time, your "cleanup" could throw the other 
thread off the rails.

The good news is that the above call only sets the time-specific 
portions of the locale, which we don't mess with anywhere else. So 
ideally we should call `setlocale(LC_TIME,"")` somewhere on program 
startup, and never look back.


> (a) Lying some. Unsure what might happen with the boost variant over the 
> pure c++11 one for now, but the latter didn't account for daylight 
> savings adjustments which also makes datetime(), %z and %Z less than 
> precisely useful.

The v4.0 variant doesn't respect daylight savings zone? Yikes!

That'll be another problem to solve then.

Post a reply to this message

On 2021-07-30 2:29 PM (-4), clipka wrote:
> 
> - When users see a date or time, they will usually expect it to indicate
> local time. To achieve that, the parameter passed to `datetime()` would
> have to be of local time flavor.
> 
> This speaks heavily in favor of making `now` return local time, as
> opposed to UTC.
> 
> 
> I think it can be argued that local time is of far more relevance to
> most users than UTC.
> 
> [snip]
> 
> Actually, no - in this case `now` returning local time is not a
> Unix/Linux bug (or, more to the point, not a "boost on Unix/Linux bug"),
> but rather proper intrinsic behavior of the new implementation I chose.
> 
> 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
box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
in behavior?

Post a reply to this message

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
> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
> in behavior?

I think I do, yes.

The current behavior appears to be quite inconsistent across platforms 
and systems and whatnot.

Post a reply to this message

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

On 7/28/21 3:16 PM, William F Pokorny wrote:

> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")
> 
> I've gotten back:
> 

> 
> because the default format strings has a 'Z' on the end where I suspect 
> ' %Z' was intended.

Z is for Zulu Time Zone, often used in aviation and the
military as another name for UTC +0.

tTh

-- 
+-------------------------------------------------------------------+
|                      sphinx of black quartz, judge my vow.        |
+-------------------------------------------------------------------+

Post a reply to this message

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

In my case, #debug concat("v3.8 default -> ",datetime(now),"\n")

Running the Windows version under Windows 10.

Post a reply to this message

Am 28.07.2021 um 15:16 schrieb William F Pokorny:

> Just to toss it out there, for as long as I've used datetime(now) as in:
> 
> #version 3.8;
> #debug concat("v3.8 default -> ",datetime(now),"\n")

Can you put some estimate on "as long as I've used datetime(now)"? 
Further back than 2019?

If so, can you remember whether you already got local time out of the 
function back then, or whether it could originally have been UTC after all?

Post a reply to this message