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