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")
> 
> I've gotten back:
> 

> 
> because the default format strings has a 'Z' on the end where I suspect 
> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the 
> time offset more general.

The `datetime` function with default values works as documented:

"The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"


I'm not the author of that functionality, but according to my 
understanding, this is entirely intentional:

Since the information provided by "now" is based on UTC, and the 
`strftime` conversion specifiers are time zone agnostic(*), the printed 
date and time are also with respect to UTC.

In full compliance with ISO 8601, this is indicated by appending a 
literal uppercase `Z` right after the time, which is the official time 
zone designator for UTC.


(*)Except for `%Z` or `%z` of course.

Speaking of which: Appending either of those instead of "Z" would 
actually give a wrong time, unless you first convert `now` to local time.

Also, per ISO 8601 any time zone designator should be appended to the 
time without any intervening space.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
>> also, while on 'povr', I
>> ran into trouble viewing font glyphs >= chr(256).
>
> True my text{} isn't POV-Ray's exactly... Is this something unique to
> the povr branch? Off the top of my head, this likely normal unless using
> a unicode string specifications.

not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
output.

also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
yet checked to find out why (have to install one or two of the fonts first).


regards, jr.

Post a reply to this message

Attachments:
Download 'tabu_cmp.png' (832 KB)

Preview of image 'tabu_cmp.png'

Am 29.07.2021 um 10:35 schrieb jr:

>>> also, while on 'povr', I
>>> ran into trouble viewing font glyphs >= chr(256).
>>
>> True my text{} isn't POV-Ray's exactly... Is this something unique to
>> the povr branch? Off the top of my head, this likely normal unless using
>> a unicode string specifications.
> 
> not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
> 'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
> output.

povr is based on those rolled-back alpha versions, right? Then color me 
unsurprised.

Did I ever, maybe in passing, mention that POV-Ray v3.7's behavior 
(which we strive to emulate in v3.8) regarding non-ASCII characters and 
fonts is seriously borked?


> also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
> display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
> yet checked to find out why (have to install one or two of the fonts first).

It is theoretically possible for fonts to provide a non-empty glyph for 
the ASCII "space" character. I guess this could go unnoticed in most 
programs, as they would typically use operating systems calls to render 
text, which in turn could conveivably give special treatment to ASCII 
"space" by simply inserting a gap according to the character's width.

I think POV-Ray does not currently do that, and instead treats "space" 
like any other character, i.e. it may or may not have a visible glyph.


But I think we're digressing a bit from the original thread...

Post a reply to this message

On 7/28/21 5:53 PM, clipka wrote:
> 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")
>>
>> I've gotten back:
>>

>>
>> because the default format strings has a 'Z' on the end where I 
>> suspect ' %Z' was intended. In the povr branch I changed to ' %z' as I 
>> think the time offset more general.
> 
> The `datetime` function with default values works as documented:
> 
> "The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"
> 
> 
> I'm not the author of that functionality, but according to my 
> understanding, this is entirely intentional:
> 
> Since the information provided by "now" is based on UTC, and the 
> `strftime` conversion specifiers are time zone agnostic(*), the printed 
> date and time are also with respect to UTC.
> 
> In full compliance with ISO 8601, this is indicated by appending a 
> literal uppercase `Z` right after the time, which is the official time 
> zone designator for UTC.
> 
> 
> (*)Except for `%Z` or `%z` of course.
> 
> Speaking of which: Appending either of those instead of "Z" would 
> actually give a wrong time, unless you first convert `now` to local time.
> 
> Also, per ISO 8601 any time zone designator should be appended to the 
> time without any intervening space.

Supposing the SDL:

    #debug concat("",datetime(now),"\n")
    #debug concat("",datetime(-100000),"\n") // (*)

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

     Thu 29 Jul 2021 07:15:12 AM EDT

The v3.8 branch returns:

     2021-07-29 06:15:12Z  <-- Not current Zulu time... (**)
     1726-03-18 00:00:00Z

The povr branch returns:

     2021-07-29 06:15:13 -0400 <-- Not my current dst time. Offset wrong.
     2021-07-29 07:15:13 -0400 <-- This is correct.

Bill P.

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

(**) Using %Z would add EDT instead of EST (locally), which is also 
correct. Though any given reader must know what the local %Z dst is no 
matter where povray/datetime(now) was run or where they live
compared to the person who did run it.

Post a reply to this message

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