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

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

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

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

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

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

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