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