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