POV-Ray : Newsgroups : povray.beta-test : POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10 : Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10 Server Time
23 Jun 2024 08:06:11 EDT (-0400)
  Re: POV-Ray v3.8.0-beta 1 - Parse error using "%s" in Win10  
From: clipka
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.