![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 28 Jul 2021 17:53:02
Message: <6101d1be$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
hi,
William F Pokorny <ano### [at] anonymous org> 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'
![tabu_cmp.png](/povray.beta-test/attachment/%3Cweb.6102686ce398ba995e0fed26cde94f1%40news.povray.org%3E/tabu_cmp.png?ttop=443662&preview=1)
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 29 Jul 2021 06:29:32
Message: <6102830c@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 29 Jul 2021 07:45:12
Message: <610294c8$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 29 Jul 2021 08:54:35
Message: <6102a50b$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 29 Jul 2021 17:43:55
Message: <6103211b$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 30 Jul 2021 10:00:59
Message: <6104061b$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 30 Jul 2021 14:29:34
Message: <6104450e$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Cousin Ricky
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 30 Jul 2021 17:38:49
Message: <61047169@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 30 Jul 2021 19:13:23
Message: <61048793$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |