|
|
|
|
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 31 Jul 2021 04:18:55
Message: <6105076f$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: tth
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 31 Jul 2021 10:03:13
Message: <61055821@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: Alain Martel
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 31 Jul 2021 11:10:15
Message: <610567d7$1@news.povray.org>
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 11 Aug 2021 07:13:43
Message: <6113b0e7$1@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 11 Aug 2021 09:09:21
Message: <6113cc01$1@news.povray.org>
|
|
|
| |
| |
|
|
On 8/11/21 7:13 AM, 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")
>
> Can you put some estimate on "as long as I've used datetime(now)"?
> Further back than 2019?
Guessing 2018 or there about - certainly your new c++11 code over the
boost stuff - but I don't remember the exact timing. We could look at
the commit messages I guess.
>
> 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?
Yes, as I said in answer to Cousin_Ricky, I tripped myself up on using
the v3.8 branch point for povr as v3.8 beta 1 due a screw up in my
wrapper script. The latter (now)- with the original boost code does
return utc - but the %z %Z options in datetime don't work. Sticking with
v3.8 beta <n> as is - at least as far as my Ubuntu machine goes - is an
OK option I think.
Other changes to now/datetime could wait for v4.0. But, I'm not sure
what others see for v3.8.
Complete aside... I have a vague recollection of a compile time
environment variable for some compiler which let users select whether
std::time() - the 'c' time - would return utc or local time. But, maybe
it was a fever dream... :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 11 Aug 2021 11:10:46
Message: <6113e876@news.povray.org>
|
|
|
| |
| |
|
|
Am 11.08.2021 um 15:09 schrieb William F Pokorny:
> wrapper script. The latter (now)- with the original boost code does
> return utc - but the %z %Z options in datetime don't work. Sticking with
> v3.8 beta <n> as is - at least as far as my Ubuntu machine goes - is an
> OK option I think.
Can you elaborate on the "%z %Z don't work"?
Note that placing `%z` or `%Z` in the string passed to `strftime()`
doesn't magically alter how that function interprets the data it
receives. It just inserts the identifier for whatever timezone the
system has been configured to use, period. It is the responsibility of
the software developer (which in this particular case and current state
of affairs eventually means the scene author) to make sure that the data
passed to `strftime()` is local time when using `%z` or `%Z` (or no
timezone identifier at all, for that matter) and UTC when appending a
literal `Z` to indicate UTC.
There is one additional caveat in that an additional data field needs to
be set up properly in order for `%z` or `%Z` to print the proper
timezone information when DST would be in effect at the point in time
specified. If that is not done, the timezone printed will not properly
adapt to DST.
Since the code was designed for UTC, the DST field was never really
considered, and may be set up completely wrong.
If the "don't work" symptoms you observed can't be explained by either
of the above caveats, then I'd like to learn more about it.
> Complete aside... I have a vague recollection of a compile time
> environment variable for some compiler which let users select whether
> std::time() - the 'c' time - would return utc or local time. But, maybe
> it was a fever dream... :-)
Maybe what you remember was actually a preprocessor macro in some
software package, to let it know what was implemented in the library?
The boost source code hints that an obscure IDE for embedded system
development called Metrowerks CodeWarrior would use local time, rather
than utc, throughout the date/time-related portions of its C library.
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 11 Aug 2021 16:37:58
Message: <61143526$1@news.povray.org>
|
|
|
| |
| |
|
|
On 8/11/21 11:10 AM, clipka wrote:
> Can you elaborate on the "%z %Z don't work"?
Some. The failures are varied depending upon the format string.
SDL:
//---
#debug concat("%z ---> <",datetime(now,"%z"),">\n")
#debug concat("%Z ---> <",datetime(now,"%Z"),">\n")
// For the lines above
// 3.7.0.8 - Invalid formatting code in format string, or
// resulting string too long.
// v3.8 b 1 - Invalid formatting code in format string, or
// resulting string too long.
// ~master - Invalid formatting code in format string, or
// resulting string too long.
// povr - %z ---> <-0400>
// %Z ---> <EDT>
#debug concat("%z ---> <",datetime(now,"%c %z"),">\n")
#debug concat("%Z ---> <",datetime(now,"%c %Z"),">\n")
// For the lines above
// 3.7.0.8 - %z ---> <Wed 11 Aug 2021 07:58:53 PM >
// %Z ---> <Wed 11 Aug 2021 07:58:53 PM > (**)
// v3.8 b 1 - %z ---> <Wed 11 Aug 2021 07:58:53 PM >
// %Z ---> <Wed 11 Aug 2021 07:58:53 PM > (**)
// ~master - %z ---> <Wed 11 Aug 2021 03:05:50 PM > (***)
// %Z ---> <Wed 11 Aug 2021 03:05:50 PM > (***)
// povr (*) - %z ---> <Wed 11 Aug 2021 03:05:50 PM EDT -0400>
// %Z ---> <Wed 11 Aug 2021 03:05:50 PM EDT EDT>
// (*) The time isn't accounting for dst though %z,%Z correct.
// (**) The %c should include a %Z string of its own and does not.
// (***) Above issue and time not the actual utc time.
#error "Parse test. Stop early."
//---
As I believe I mentioned somewhere else, I'm not sure what all doesn't
work with respect to formatting given the boost code being used doesn't
set up all the fields needed to use the complete set of strftime()
formatting.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 11 Aug 2021 17:55:43
Message: <6114475f@news.povray.org>
|
|
|
| |
| |
|
|
Am 11.08.2021 um 22:37 schrieb William F Pokorny:
> //---
Hah!
This one took me a while, and I was on the verge of asserting that
`strftime` must be broken on your machine. Because whatever `strftime`
does, it should NOT be reporting an error when confronted with these
parameters.
The kicker is: It doesn't.
What happens it that - for _some_ reason - `strftime` can't properly
determine the time zone (e.g. because it doesn't know whether DST is in
effect or not).
In that case, it is contractually obliged to replace `%z` or `%Z` with
an empty string.
Which, in this very special case, leads to a completely empty result string.
Which means that `strftime` return a value of 0, because that's what it
does if it doesn't encounter a fatal error: It returns the number of
characters placed in the result string.
Zero.
Which also happens to be the value it is contractually obliged to return
if it runs out of space to write the result string to.
So POV-Ray panics, imagining there to be a serious problem when there is
none.
>
> // (*) The time isn't accounting for dst though %z,%Z correct.
> // (**) The %c should include a %Z string of its own and does not.
Should it though?
The C (and by extension C++) standard mandates that `strftime` replace
That's it, no other specification for it. Whether that is to include any
time zone information is, I would argue, up to "the locale". For the `C`
locale, for instance, the standard specifically mandates that a timezone
specifier is NOT included in the "%c" replacement text.
Also, even if the locale does happen to include a `%Z`, it makes sense
that it also gets replaced by an empty string, just like an explicit `%Z`.
> // (***) Above issue and time not the actual utc time.
Not at all surprised there.
Should match your local non-DST time.
> As I believe I mentioned somewhere else, I'm not sure what all doesn't
> work with respect to formatting given the boost code being used doesn't
> formatting.
From all of my understanding, only the timezone identifier (either
explicitly, or implicitly such as via `%c`) should suffer.
Okay, I guess the takeway lesson here is that as implemented up to (and
including) v3.8.0-beta-1, your system doesn't seem to have enough
information to decide what timezone is applicable, presumably because
the info whether DST is in effect for the date isn't explicitly set, and
your runtime library's `strftime` function does not make any attempt to
figure it our for itself.
Which begs the question, what exactly does povr do differently?
Post a reply to this message
|
|
| |
| |
|
|
From: William F Pokorny
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 12 Aug 2021 07:01:22
Message: <6114ff82$1@news.povray.org>
|
|
|
| |
| |
|
|
On 8/11/21 5:55 PM, clipka wrote:
> Should it though?
Understanding what you are saying below, my answer is still, yes,
because it is what my locale does if the information is available. In
other words POV-Ray's %c result should match what my 'date' command
returns.
Aside: IIRC, there's a huge text file with all sorts of locale
information in it that gets used to create code for compilers and the
like. I've never tried to find it. I do sort of wonder what it looks like.
Hmmm, just had a thought about that line of code in parser_strings.cpp:
setlocale(LC_TIME,"");
I didn't play with that at all. Wondering at the moment what happens if
we move that call ahead of:
std::tm t =
boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));
Could it be we are not getting some fields because at that call we are
effectively running: setlocale(LC_TIME,"C") ?
> The C (and by extension C++) standard mandates that `strftime` replace
> That's it, no other specification for it. Whether that is to include any
> time zone information is, I would argue, up to "the locale". For the `C`
> locale, for instance, the standard specifically mandates that a timezone
> specifier is NOT included in the "%c" replacement text.
>
> Also, even if the locale does happen to include a `%Z`, it makes sense
> that it also gets replaced by an empty string, just like an explicit `%Z`.
>
>> // (***) Above issue and time not the actual utc time.
>
> Not at all surprised there.
> Should match your local non-DST time.
>
>> As I believe I mentioned somewhere else, I'm not sure what all doesn't
>> work with respect to formatting given the boost code being used
>> strftime() formatting.
>
> From all of my understanding, only the timezone identifier (either
> explicitly, or implicitly such as via `%c`) should suffer.
>
>
> Okay, I guess the takeway lesson here is that as implemented up to (and
> including) v3.8.0-beta-1, your system doesn't seem to have enough
> information to decide what timezone is applicable, presumably because
> the info whether DST is in effect for the date isn't explicitly set, and
> your runtime library's `strftime` function does not make any attempt to
> figure it our for itself.
>
> Which begs the question, what exactly does povr do differently?
The povr code looks like:
std::time_t tt;
if (FractionalDays <= -1e5) // (****)
{
tt = std::time(nullptr);
}
else
{
tt = std::mktime(&t);
}
setlocale(LC_TIME,""); // Get the local preferred format
vlen = strftime(val, PARSE_NOW_VAL_LENGTH, FormatStr,
std::localtime(&tt));
Suppose, if you were to use something like it, you might make use too of
std::gmtime() - depending on settings.
(****) - Yep, my old brain failed too to remember my own trigger for
generating the time_t information immediately. At one point I was
thinking of using any value prior to epoch, but apparently I didn't.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
From: clipka
Subject: Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10
Date: 12 Aug 2021 07:27:59
Message: <611505bf$1@news.povray.org>
|
|
|
| |
| |
|
|
Am 12.08.2021 um 13:01 schrieb William F Pokorny:
> Hmmm, just had a thought about that line of code in parser_strings.cpp:
>
> setlocale(LC_TIME,"");
>
> I didn't play with that at all. Wondering at the moment what happens if
> we move that call ahead of:
>
> std::tm t =
> boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));
>
> Could it be we are not getting some fields because at that call we are
> effectively running: setlocale(LC_TIME,"C") ?
If that were the case, then
#declare ThrowAway = datetime(now);
#debug concat(datetime(now),"\n")
should change the behavior, since the first invocation of `datetime`
should switch the time locale to the system default, and we're never
switching it back, so the next invocation of `datetime` should start
with the system default time locale already selected.
But I'd be surprised if that would work. By definition, `std::time_t` is
positively supposed to represent universal time in some way or form, so
converting that to `std::tm` should still result in "yeah, here's your
date information, but as for DST, well, that's not really applicable
here at all because UTC."
I thknk what should really happen is that we should perform the
conversion from `std::time_t` to `std::tm` via `std::gmtime()` when
converting for UTC, and via `std::localtime()` when converting for local
time. I'm quite confident that the latter should set the DST flag as
appropriate. And it will also definitely take care of adjusting for time
zone, so we can use a `now` that's always based on UTC.
The povr code also using `std::localtime()` confirms that this should
indeed actually work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|