I am currently testing a macro by jr.: tabulated.inc. In one of his demo 
scenes he uses the following line:

#declare seed_ = val(datetime(now,"%s"));

Using Windows10, and POV-Ray v3.8.0-beta 1, I get the following error:

Parse Error: Invalid formatting code in format string, or resulting 
string too long.

I contacted jr. about this and he answered the following:

"POV-Ray's documentation says the "..optional STRING parameter should
conform to the same formatting as that of the strftime() C function."
and (lowercase) "%s" is documented as described and used.  I assume
that the Windows 'strftime()' does not provide that option?  else it
would be a POV-Ray on Windows bug, I guess."

I mention this error also on behalf of jr. I am not sure about which 
system jr. uses, obviously not Windows, but he will jump in if you need 
to know.

-- 
Thomas

Post a reply to this message

hi,

Thomas de Groot <tho### [at] degrootorg> wrote:

(thanks, could not post this as I have no MS Windows machine)


> #declare seed_ = val(datetime(now,"%s"));

just to confirm, this works on all Linux systems I have access to, incl a Debian
VM with (oldest) POV-Ray-3.7.0.8.


regards, jr.

Post a reply to this message

On 25/07/2021 10:33, jr wrote:

> just to confirm, this works on all Linux systems I have access to, incl a Debian
> VM with (oldest) POV-Ray-3.7.0.8.

Ok on Mac.


#declare DateString = datetime(now,"%s");
#debug concat("DateString     = ",DateString,"\n")

#declare DateNum = val(datetime(now,"%s"));
#debug concat("DateNum        = ",str(DateNum,0,0),"\n")

#declare LongDateString = datetime(now,"%A %e %B %Y %H:%M:%S");
#debug concat("LongDateString = ", LongDateString,"\n")


Result :

DateString     = 1627201022
DateNum        = 1627201022
LongDateString = Sunday 25 July 2021 10:17:02



-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

Am 25.07.2021 um 09:45 schrieb Thomas de Groot:

> #declare seed_ = val(datetime(now,"%s"));

> "POV-Ray's documentation says the "..optional STRING parameter should
> conform to the same formatting as that of the strftime() C function."
> and (lowercase) "%s" is documented as described and used.  I assume
> that the Windows 'strftime()' does not provide that option?  else it
> would be a POV-Ray on Windows bug, I guess."

 From the Linux man page on die.net (https://linux.die.net/man/3/strftime):
--------------------------------------------------------------
%s

The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC). 
(TZ)
--------------------------------------------------------------

For information on what "(TZ)" means, see further on that page:

--------------------------------------------------------------
Conforming To

SVr4, C89, C99. There are strict inclusions between the set of 
conversions given in ANSI C (unmarked), those given in the Single UNIX 
Specification (marked SU), those given in Olson's timezone package 
(marked TZ), and those given in glibc (marked GNU), except that %+ is 
not supported in glibc2. On the other hand glibc2 has several more 
extensions. POSIX.1 only refers to ANSI C; POSIX.2 describes under 
date(1) several extensions that could apply to strftime() as well. The 
%F conversion is in C99 and POSIX.1-2001.
--------------------------------------------------------------

For a list of values officially supported by standard C/C++, see 
https://en.cppreference.com/w/c/chrono/strftime.


TL;DR:

"%s" is a non-standard extension to the `strftime` format, that is not 
universally supported.


Also note that in POV-Ray, `now` already is a numeric value (albeit in 
days, and with 0 corresponding to 2000-1-1, 00:00:00 am UTC). It should 
be trivial to convert to a Unix timestamp without the use of `datetime` 
and `val`, using simple scalar math.

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 25.07.2021 um 09:45 schrieb Thomas de Groot:
>
> > #declare seed_ = val(datetime(now,"%s"));
> ...
> Conforming To
>
> SVr4, C89, C99. ...
> TL;DR:
>
> "%s" is a non-standard extension to the `strftime` format, that is not
> universally supported.

do you have a reference for the "non-standard", please?  cannot see a mention on
the pages I looked at, including
<https://man7.org/linux/man-pages/man3/strftime.3.html>.


regards, jr.

Post a reply to this message

Am 25.07.2021 um 15:28 schrieb jr:

> do you have a reference for the "non-standard", please?  cannot see a mention on
> the pages I looked at, including
> <https://man7.org/linux/man-pages/man3/strftime.3.html>.

(1)

The official reference for the fact that it's non-standard would be the 
official documentation of the C and C++ standards: ISO/IEC 9899 and 
ISO/IEC 14882, respectively, in whatever revision of the language you're 
looking at. Of those, the C documentation is the more interesting, as 
the C++ standard only defines it by reference.

The non-standard status of "%s" is documented in ISO-IEC 9899 by 
absence: It is not mentioned, therefore it is non-standard.

I do not have access to an authoritative copy of any revision of ISO/IEC 
9899 aside a PDF copy of good old ANS/ISO 9899-1990, but there the 
relevant information would be found on page 174, in section 7.12.3.5, 
"The strftime function"

For ISO/IEC 9899:1999, that forms the main basis for C++, I only have 
access to drafts (access to authoritative ISO/IEC standard documents 
requires a license fee). In a PDF titled "ISO/IEC Committee Draft - May 
6, 2005 ISO/IEC 9899:TCs" (which to the best of my knowledge differs 
from ISO/IEC 9899:1999 only in "bugfixes"), the relevant information 
would be found on page 7.23.3.5, "Tthe strftime function".

In the official ANSI PDF release of ISO/IEC 14882:2011(E), the relevant 
information can be found on page 619, section 20.11.8 [date.time] "Date 
and time functions", but it only references the C standard. (The 
footnote explicitly listing conversion specifies from C seems to be 
intended to only explicitly affirm that C++11 supports those specifiers 
added in C99, rather than the smaller set in C89.)


(2)

The page I've linked to, "cppreference.com", is dedicated to faithfully 
documenting the official standard in a more accessible format, and has 
proven quite reliable in being true to the standards and their versions.

The page you're citing documents what is implemented in Linux' glibc. It 
is not authoritative about what to expect from `strftime` on a 100% pure 
standard-conformant system.


(3)

The page you liked to, under "%s", also lists effectively the same 
information as the other man page source I cited:

--------------------------------------------------------------
%s     The number of seconds since the Epoch, 1970-01-01 00:00:00
               +0000 (UTC). (TZ) (Calculated from mktime(tm).)
--------------------------------------------------------------

Again, note the "(TZ)" here. In the section titled "CONFORMING TO", it 
also explains what this "(TZ)" marker means, again just like the man 
page source I cited:

--------------------------------------------------------------

        SVr4, C89, C99.  There are strict inclusions between the set of
        conversions given in ANSI C (unmarked), those given in the Single
        UNIX Specification (marked SU), those given in Olson's timezone
        package (marked TZ), and those given in glibc (marked GNU),
        except that %+ is not supported in glibc2.  On the other hand
        glibc2 has several more extensions.  POSIX.1 only refers to ANSI
        C; POSIX.2 describes under date(1) several extensions that could
        apply to strftime() as well.  The %F conversion is in C99 and
        POSIX.1-2001.

--------------------------------------------------------------

In other words:
- If it is marked "(GNU)", it is supported by glibc.
- If it is marked "(TZ)", it is supported by glibc and "Olson's timezone 
package"
- If it is marked "(SU)", it is supported by glibc and "Olson's timezone 
package", and standardized for Unix in the Single UNIX Specification.
- If it is unmarked, it is supported by glibc and "Olson's timezone 
package", and standardized for Unix in the Single UNIX Specification and 
ANSI C (which in this case appears to mean ANSI-standard C in general, 
not specifically C89 as would usually be the case. ).


(4)

It may be worth noting that Linux' strftime is _not_ in violation of the 
C (and, by extension, C++) standard, which explicitly states: "If a 
conversion specilier is not one of the above. the behavior is 
undefined." In other words, "%s" may crash the program, produce "F*** 
you" as output, or convert the time to a decimal rendition of the number 
of seconds between the very start of 1970 and the specified time. Any of 
these behaviors are acceptable per the C/C++ standard.

Post a reply to this message

Am 25.07.2021 um 23:23 schrieb clipka:

> For ISO/IEC 9899:1999, that forms the main basis for C++, I only have 

That was supposed to read "... the main basis for C++11". Which is the 
minimum language revision required to build POV-Ray v3.8.

(In POV-Ray v3.7, which requires C++99 as the minimum language version, 
the earlier C89 standard would apply, which is even more limited.)

Post a reply to this message

It might be worth weaving the following information into the 
documentation of our "datetime" function:

-------------------------

Which codes are supported depends on the platform POV-Ray is compiled 
an/or running on.

In POV-Ray v3.7, the following codes can be expexted to work reliably:

a,A,b,B,c,d,H,I,j,m,M,p,S,U,w,W,x,X,y,Y,Z,%

In POV-Ray v3.8, the following additional codes can be expexted to work 
reliably:

a,A,b,B,c,C,d,D,e,F,g,G,h,H,I,j,m,M,n,p,r,R,S,t,T,u,U,V,w,W,x,X,y,Y,z,Z,%

-------------------------

(Side note: The C99/C++11 standards define additional two-letter codes 
starting with E or O; while those should also work in POV-Ray v3.8, 
their result _will_ differ between systems, depending on the language 
settings of the computer.


(Also, note to self and fellow developers: It may be worth adding a 
check in POV-Ray itself, to verify whether the formatting string 
submitted is actually portable across platforms, and warn if it isn't.)

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:

I thank you for the (detailed) clarification re status of "%s" (and yr time).  I
dug up a PDF (N1256, Committee Draft 7.9.2007) and was shocked (sort of) to find
no mention of "%s".

and also a big thank you for writing "..in POV-Ray, `now` already is a numeric
value..", this has cleared up a complete misunderstanding.  the documentation
says 'now' is a "keyword" and only illustrates its use in a 'datetime()' call.
I had not realised that 'now' can be used outside 'datetime()'.  :-)  so the
demo scene TdG mentioned simply needs a (fairly) reliable unique seed for the
RNG, whenever it's rendered.  made a couple of quick tests with 'now', and am
thinking of using something like the following to replace the
'datetime(now,"%s")', and would appreciate comment(s):

#declare seed_ = mod((now-int(now))*1e16,1e9);


> It might be worth weaving the following information into the
> documentation of our "datetime" function:

and perhaps improve description of 'now'.


regards, jr.

Post a reply to this message

On 2021-07-26 4:34 AM (-4), jr wrote:
> 
> and perhaps improve description of 'now'.

The 'now' keyword is documented in the float built-in variables section
of the 3.8 reference manual (as it should be), but unlike most of the
other variables in that section, the word 'now' is not its own header,
so it is easy to miss.  (The same is true of the 'version' keyword.)

The documentation of 'datetime' could use a cross reference to the 'now'
description.

Post a reply to this message

Am 26.07.2021 um 10:34 schrieb jr:

> demo scene TdG mentioned simply needs a (fairly) reliable unique seed for the
> RNG, whenever it's rendered.  made a couple of quick tests with 'now', and am
> thinking of using something like the following to replace the
> 'datetime(now,"%s")', and would appreciate comment(s):
> 
> #declare seed_ = mod((now-int(now))*1e16,1e9);

- Variable name should use uppercase as the first letter. Just saying.

- No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);` 
already effectively does a `mod` operation with a modulus of 2^32 (ca. 4e9).

- Taking the time of day, rather than the running total, is a smart move 
I probably wouldn't have thought of, and had me thinking thrice to 
figure out whether it even has any advantage. (My preliminary 
conclusion: I think it does.)

- Multiplying with 1e16 seems excessive. The value is given in days, and 
has a precision of microseconds at best; 8.64e10 would be the ideal 
factor in that case. Some systems may even provide timers as slow as one 
tick mer millisecond, in which case there would be little point in using 
  a factor larger than 8.64e6.


There might be some point in multiplying with a very large number and 
then applying `mod`, so that seeds quickly diverge. But that doesn't 
work when the multiplying factor is a multiple of the modulus - you'd 
ideally want coprime values for that, otherwise you're not shuffling 
around information, you're just ditching digits.

This should be easy to accomplish by using any odd (in the literal 
sense) multiplier, while ditching your own mod and relying on the 
inbuilt mod 2^32 operation. I have a hunch that numbers with a 
well-balanced number of binary ones and zeros would be ideal.

The following might do nicely:

     #declare seed_ = (now-int(now))*(1e9+1);

Post a reply to this message

Le 2021-07-26 à 14:46, clipka a écrit :
> Am 26.07.2021 um 10:34 schrieb jr:
> 
>> demo scene TdG mentioned simply needs a (fairly) reliable unique seed 
>> for the
>> RNG, whenever it's rendered.  made a couple of quick tests with 'now', 
>> and am
>> thinking of using something like the following to replace the
>> 'datetime(now,"%s")', and would appreciate comment(s):
>>
>> #declare seed_ = mod((now-int(now))*1e16,1e9);
> 
> - Variable name should use uppercase as the first letter. Just saying.
> 
> - No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);` 
> already effectively does a `mod` operation with a modulus of 2^32 (ca. 
> 4e9).
> 
> - Taking the time of day, rather than the running total, is a smart move 
> I probably wouldn't have thought of, and had me thinking thrice to 
> figure out whether it even has any advantage. (My preliminary 
> conclusion: I think it does.)
> 
> - Multiplying with 1e16 seems excessive. The value is given in days, and 
> has a precision of microseconds at best; 8.64e10 would be the ideal 
> factor in that case. Some systems may even provide timers as slow as one 
> tick mer millisecond, in which case there would be little point in using 
>   a factor larger than 8.64e6.
> 
> 
> There might be some point in multiplying with a very large number and 
> then applying `mod`, so that seeds quickly diverge. But that doesn't 
> work when the multiplying factor is a multiple of the modulus - you'd 
> ideally want coprime values for that, otherwise you're not shuffling 
> around information, you're just ditching digits.
> 
> This should be easy to accomplish by using any odd (in the literal 
> sense) multiplier, while ditching your own mod and relying on the 
> inbuilt mod 2^32 operation. I have a hunch that numbers with a 
> well-balanced number of binary ones and zeros would be ideal.
> 
> The following might do nicely:
> 
>      #declare seed_ = (now-int(now))*(1e9+1);

When I want coprimes, I often plug in pi in the mix, or use two values 
that differ by 1. It could be something like :

#declare Seed_ = mod(now*pi*100000000, 87654321);

Post a reply to this message

hi,

clipka <ano### [at] anonymousorg> wrote:
> Am 26.07.2021 um 10:34 schrieb jr:
>> #declare seed_ = mod((now-int(now))*1e16,1e9);
>
> - Variable name should use uppercase as the first letter. Just saying.

:-)  I can live with camelcase like 'fooBarBaz' but..


> - No need for `mod`, as the seeding via `#declare MyRNG = seed(seed_);`
> already effectively does a `mod` operation with a modulus of 2^32 (ca. 4e9).
>
> - Taking the time of day, rather than the running total, is a smart move
> I probably wouldn't have thought of, and had me thinking thrice to
> figure out whether it even has any advantage. (My preliminary
> conclusion: I think it does.)
>
> - Multiplying with 1e16 seems excessive. The value is given in days, and
> has a precision of microseconds at best; 8.64e10 would be the ideal
> factor in that case. Some systems may even provide timers as slow as one
> tick mer millisecond, in which case there would be little point in using
>   a factor larger than 8.64e6.
>
> There might be some point in multiplying with a very large number and
> then applying `mod`, so that seeds quickly diverge. But that doesn't
> work when the multiplying factor is a multiple of the modulus - you'd
> ideally want coprime values for that, otherwise you're not shuffling
> around information, you're just ditching digits.

I guess that ("ditching digits") was the idea.  take away the "constant" part,
shift the decimal point by 16 positions (I was looking at 'now' with
'str(now,0,16)', and all positions are in use/change), then "truncate".


> ...
> The following might do nicely:
>
>      #declare seed_ = (now-int(now))*(1e9+1);

it does (and I'll be using that).  output is more like using "%s", ie
incrementing, than with the "diverging" 'mod()'.


AM: yes, 'pi', neat, though not for this project.  thanks.


regards, jr.

Post a reply to this message

On 7/25/21 4:33 AM, jr wrote:
> hi,
> 
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
> (thanks, could not post this as I have no MS Windows machine)
> 
> 
>> #declare seed_ = val(datetime(now,"%s"));
> 
> just to confirm, this works on all Linux systems I have access to, incl a Debian
> VM with (oldest) POV-Ray-3.7.0.8.
> 

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")

I've gotten back:

  v3.8 default -> 2021-07-28 08:11:16Z

because the default format strings has a 'Z' on the end where I suspect 
' %Z' was intended. In the povr branch I changed to ' %z' as I think the 
time offset more general.

  v3.8 (povr) default -> 2021-07-28 08:15:15 -0400

Bill P.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> 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")
>
> I've gotten back:
>
>   v3.8 default -> 2021-07-28 08:11:16Z
>
> because the default format strings has a 'Z' on the end where I suspect
> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
> time offset more general.
>
>   v3.8 (povr) default -> 2021-07-28 08:15:15 -0400

is this new?  because does not work for me, see below.  also, while on 'povr', I
ran into trouble viewing font glyphs >= chr(256).  (and thanks for raising the
"constant rounding" thing)


regards, jr.




jr@swift:6:wfp$ c### [at] tpov

#version 3.8;

global_settings {assumed_gamma 1}
box {0,1}

#declare s_ = datetime(now);

#debug concat("datetime v3.8 default: '",s_,"'.\n")

jr@swift:7:wfp$ povr t.pov -gr -gs -d -f
Persistence of Vision(tm) Ray Tracer   (see --license)
Copyright 1991-2021 Persistence of Vision Raytracer Pty. Ltd.
Version 3.8.0-x.povr_1984d6ea.unofficial
  (g++ 5.5.0 @ x86_64-slackware-linux-gnu)
This is an unofficial version compiled by: <jr### [at] swiftlan>

Dynamic optimizations:
  CPU detected: Intel,SSE2,AVX,AVX2,FMA3
  Noise generator: avx2fma3-intel (hand-optimized by Intel)

==== [Parsing...] ==========================================================
datetime v3.8 default: '2021-07-28 15:31:42Z'.
==== [Rendering...] ========================================================
POV-Ray finished

Post a reply to this message

On 7/28/21 11:38 AM, jr wrote:
> hi,
> 
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> because the default format strings has a 'Z' on the end where I suspect
>> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the
>> time offset more general.
>>
>>    v3.8 (povr) default -> 2021-07-28 08:15:15 -0400
> 
> is this new?  because does not work for me, see below.  

Relatively, I guess. Looks like I updated this with a commit on:

Date:   Fri Jun 11 06:18:44 2021 -0400

where I changed datetime() to optionally generate a time accounting for 
the local daylight savings time datetime(-100000) after getting myself 
tangled up due the generated datetime() string not aligning to my local 
-dst adjusted - computer time. Only %z %Z appear to be dst aware with 
datetime() otherwise.

So... The Z to ' %z' is an update not yet published.

> also, while on 'povr', I
> ran into trouble viewing font glyphs >= chr(256).  

True my text{} isn't POV-Ray's exactly... Is this something unique to 
the povr branch? Off the top of my head, this likely normal unless using 
a unicode string specifications.

---
Aside:

In povr, I'm leaning in a direction of eliminating the text{} object... 
Or, at least, not further updating it.

Christoph has been playing with freetype and making the text{} internals 
prisms as you know. I'm thinking perhaps all characters/glyphs should 
just be include-able objects only where we'd use SDL macros to do all 
the placements for a string -- get POV-Ray, at the core, completely out 
of the text formatting game and push that sort of thing into SDL.

If you look at the text oriented macros shipped today - like 
Circle_Text(), for example, they are actually doing a lot of work to 
pull apart text{} strings character by character. When I do isosurface 
stuff with text{} strings, I often do the same to get to single 
'characters' for better performance. Effectively, pulling text{} objects 
apart - or internally doing this - for most work is a painfully 
backwards way to approach things in my opinion.

Bill P.

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")
> 
> I've gotten back:
> 
>   v3.8 default -> 2021-07-28 08:11:16Z
> 
> because the default format strings has a 'Z' on the end where I suspect 
> ' %Z' was intended. In the povr branch I changed to ' %z' as I think the 
> time offset more general.

The `datetime` function with default values works as documented:

"The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"


I'm not the author of that functionality, but according to my 
understanding, this is entirely intentional:

Since the information provided by "now" is based on UTC, and the 
`strftime` conversion specifiers are time zone agnostic(*), the printed 
date and time are also with respect to UTC.

In full compliance with ISO 8601, this is indicated by appending a 
literal uppercase `Z` right after the time, which is the official time 
zone designator for UTC.


(*)Except for `%Z` or `%z` of course.

Speaking of which: Appending either of those instead of "Z" would 
actually give a wrong time, unless you first convert `now` to local time.

Also, per ISO 8601 any time zone designator should be appended to the 
time without any intervening space.

Post a reply to this message

hi,

William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
>> also, while on 'povr', I
>> ran into trouble viewing font glyphs >= chr(256).
>
> True my text{} isn't POV-Ray's exactly... Is this something unique to
> the povr branch? Off the top of my head, this likely normal unless using
> a unicode string specifications.

not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
output.

also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
yet checked to find out why (have to install one or two of the fonts first).


regards, jr.

Post a reply to this message

Attachments:
Download 'tabu_cmp.png' (832 KB)

Preview of image 'tabu_cmp.png'

Am 29.07.2021 um 10:35 schrieb jr:

>>> also, while on 'povr', I
>>> ran into trouble viewing font glyphs >= chr(256).
>>
>> True my text{} isn't POV-Ray's exactly... Is this something unique to
>> the povr branch? Off the top of my head, this likely normal unless using
>> a unicode string specifications.
> 
> not so sure now whether 'povr' or 'povray' cause "a problem", see attached,
> 'povr' on right.  did a quick check with a Tk text and that confirms the 'povr'
> output.

povr is based on those rolled-back alpha versions, right? Then color me 
unsurprised.

Did I ever, maybe in passing, mention that POV-Ray v3.7's behavior 
(which we strive to emulate in v3.8) regarding non-ASCII characters and 
fonts is seriously borked?


> also, Tdg, while testing my macro (thanks, Thomas), found fonts where 'chr(32)'
> display as exclamation marks; with both POV-Ray alpha and yr 'povr'.  have not
> yet checked to find out why (have to install one or two of the fonts first).

It is theoretically possible for fonts to provide a non-empty glyph for 
the ASCII "space" character. I guess this could go unnoticed in most 
programs, as they would typically use operating systems calls to render 
text, which in turn could conveivably give special treatment to ASCII 
"space" by simply inserting a gap according to the character's width.

I think POV-Ray does not currently do that, and instead treats "space" 
like any other character, i.e. it may or may not have a visible glyph.


But I think we're digressing a bit from the original thread...

Post a reply to this message

On 7/28/21 5:53 PM, 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")
>>
>> I've gotten back:
>>
>>   v3.8 default -> 2021-07-28 08:11:16Z
>>
>> because the default format strings has a 'Z' on the end where I 
>> suspect ' %Z' was intended. In the povr branch I changed to ' %z' as I 
>> think the time offset more general.
> 
> The `datetime` function with default values works as documented:
> 
> "The default for the STRING parameter format is %Y-%m-%d %H:%M:%SZ"
> 
> 
> I'm not the author of that functionality, but according to my 
> understanding, this is entirely intentional:
> 
> Since the information provided by "now" is based on UTC, and the 
> `strftime` conversion specifiers are time zone agnostic(*), the printed 
> date and time are also with respect to UTC.
> 
> In full compliance with ISO 8601, this is indicated by appending a 
> literal uppercase `Z` right after the time, which is the official time 
> zone designator for UTC.
> 
> 
> (*)Except for `%Z` or `%z` of course.
> 
> Speaking of which: Appending either of those instead of "Z" would 
> actually give a wrong time, unless you first convert `now` to local time.
> 
> Also, per ISO 8601 any time zone designator should be appended to the 
> time without any intervening space.

Supposing the SDL:

    #debug concat("",datetime(now),"\n")
    #debug concat("",datetime(-100000),"\n") // (*)

And the 'date' command on my Ubuntu 20.04 computer returning:

     Thu 29 Jul 2021 07:15:12 AM EDT

The v3.8 branch returns:

     2021-07-29 06:15:12Z  <-- Not current Zulu time... (**)
     1726-03-18 00:00:00Z

The povr branch returns:

     2021-07-29 06:15:13 -0400 <-- Not my current dst time. Offset wrong.
     2021-07-29 07:15:13 -0400 <-- This is correct.

Bill P.

(*) The -100000 days is somewhat arbitrary. Just needs to be earlier 
than the unix epoch time to trigger the dst aware mode.

(**) Using %Z would add EDT instead of EST (locally), which is also 
correct. Though any given reader must know what the local %Z dst is no 
matter where povray/datetime(now) was run or where they live
compared to the person who did run it.

Post a reply to this message

Am 29.07.2021 um 13:45 schrieb William F Pokorny:

> Supposing the SDL:
> 
>     #debug concat("",datetime(now),"\n")
>     #debug concat("",datetime(-100000),"\n") // (*)
> 
> And the 'date' command on my Ubuntu 20.04 computer returning:
> 
>      Thu 29 Jul 2021 07:15:12 AM EDT
> 
> The v3.8 branch returns:
> 
>      2021-07-29 06:15:12Z  <-- Not current Zulu time... (**)
>      1726-03-18 00:00:00Z
> 
> The povr branch returns:
> 
>      2021-07-29 06:15:13 -0400 <-- Not my current dst time. Offset wrong.
>      2021-07-29 07:15:13 -0400 <-- This is correct.
> 
> Bill P.

Oh hooray.

So, after some digging, it turns out that on Linux machines, 
`boost::posix_time::microsec_clock::universal_time()` does specifically 
*NOT* do what it was designed to do (at least with the boost version 
we're bundling for Windows builds).

> (*) The -100000 days is somewhat arbitrary. Just needs to be earlier 
> than the unix epoch time to trigger the dst aware mode.

I have no idea what you're saying there. What do you need to trigger, 
and why?

Post a reply to this message

Can someone test whether the fix in this pull request actually solves 
the time zone issue?

https://github.com/POV-Ray/povray/pull/433

It should cause `datetime(now)` to print UTC (as opposed to local) time, 
while still incrementing significantly faster than once per second.


What I'm doing there is query another timer to get a second opinion. 
While that timer is of lower precision (seconds instead of 
microseconds), it should reliably give proper UTC. So by using that as a 
reference, we can adjust the high-precision timer accordingly by a 
multiple of 15 minutes, to give us high-precision UTC.

Post a reply to this message

On 7/29/21 5:43 PM, clipka wrote:
> Can someone test whether the fix in this pull request actually solves 
> the time zone issue?
> 
> https://github.com/POV-Ray/povray/pull/433
> 
> It should cause `datetime(now)` to print UTC (as opposed to local) time, 
> while still incrementing significantly faster than once per second.
> 
> 
> What I'm doing there is query another timer to get a second opinion. 
> While that timer is of lower precision (seconds instead of 
> microseconds), it should reliably give proper UTC. So by using that as a 
> reference, we can adjust the high-precision timer accordingly by a 
> multiple of 15 minutes, to give us high-precision UTC.

First, what the -1e5 argument to datetime() does in the povr branch is 
flip to code inside Parser::Parse_Datetime which uses std::time(nullptr) 
over the argument - POV-Ray's 'now' is not relevant.

---
In my testing your fix gives me the utc time as a hard coded result - 
and it's the only datetime string I can get with 'now'.

2021-07-30 12:48:35Z

What about local datetime strings with %z or %Z? The secondary issue I'd 
forgotten I hit back in June with the boost code is that:

std::tm t = 
boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));

doesn't set up the %Z and %z capability. Using both in the string format 
option gives me: "2021-07-30 12:48:35".

One can set up those fields by calling strftime() with an argument of:
std::localtime(&t), here getting EDT/-0400, but the date and time string 
is still strictly UTC - so it's not particularly useful except maybe to 
work backward to the actual time zone date and time in a uncommon / 
awkward way and to do that you'd need to know the data/time was UTC no 
matter the EDT or -0400 in the returned string.

---
I guess I see a place for a hard coded 'now' UTC/Z result - and as 
accurate an internal time/timer as we can get (is your fix at odds with 
timer use?). I don't see it as what most people will want with 
datetime(). This why I coded up a more traditional std::time(nullptr) as 
an optional mode of datetime()(a).

Aside 1: A reminder that in newer(to be v4.0) code, you moved 'now' off 
boost completely. This is in fact is the code povr uses - meaning any 
unix/linux 'bug' is in that code too.

Aside 2: The Parse_Datetime() code has too that use of:

setlocale(LC_TIME,"");

the full implications of which made me a little nervous along with the 
etting being afterward persistent. So after the strftime() call I added:

setlocale(LC_TIME,"C");

to return the setting to the C++ start up default. In a scan of the code 
I didn't pick up any other adjustments to the default locale.

Bill P.

(a) Lying some. Unsure what might happen with the boost variant over the 
pure c++11 one for now, but the latter didn't account for daylight 
savings adjustments which also makes datetime(), %z and %Z less than 
precisely useful.

Post a reply to this message

Am 30.07.2021 um 16:00 schrieb William F Pokorny:

> In my testing your fix gives me the utc time as a hard coded result - 
> and it's the only datetime string I can get with 'now'.
> 
> 2021-07-30 12:48:35Z
> 
> What about local datetime strings with %z or %Z? The secondary issue I'd 
> forgotten I hit back in June with the boost code is that:
> 
> std::tm t = 
> boost::posix_time::to_tm(boost::posix_time::from_time_t(timestamp));
> 
> doesn't set up the %Z and %z capability. Using both in the string format 
> option gives me: "2021-07-30 12:48:35".
> 
> One can set up those fields by calling strftime() with an argument of:
> std::localtime(&t), here getting EDT/-0400, but the date and time string 
> is still strictly UTC - so it's not particularly useful except maybe to 
> work backward to the actual time zone date and time in a uncommon / 
> awkward way and to do that you'd need to know the data/time was UTC no 
> matter the EDT or -0400 in the returned string.

That would require making `now` a more complicated beast than just a 
numeric value, as we can't transport timezone information in that format.

I'm not going there. Not in v3.8, at any rate. Nor am I going the povr 
route of hacking something into `datetime` to make it look up the 
current time on its own when it gets passed some magic value. Retrieving 
the current time is precisely the job of `now`.


As it currently stands, we have no sane way (in v3.8) of achieving all 
the following ideal goals:

- Have separate mechanisms to get the current point in time (`now`), and 
print a point in time (`datetime`).

- Have a simple "phrase" (combo of the above) to automatically print the 
given point in time as UTC, without extra effort, and in a way that it 
won't be mistaken for local time.

- Have a simple "phrase" (combo of the above) to automatically print the 
given point in time as local time, without extra effort, and in a way 
that it won't be mistaken for UTC.


I think the following arguments lead to the sanest solution:

- If we have `datetime` default to a string that explicitly prints any 
time zone information (as we currently do), then for the default to be 
not blatantly wrong, we limit ourselves to one "flavor" of point-in-time 
information: Either local ("%z" suffix), or UTC ("Z" suffix). If on the 
other hand we omit the time zone entirely from the default, the output 
will, for both flavors, be at least not entirely wrong.

This speaks heavily in favor of not including any time zone suffix at 
all by default, i.e. dropping the "Z" we're currently appending.

- When users see a date or time, they will usually expect it to indicate 
local time. To achieve that, the parameter passed to `datetime()` would 
have to be of local time flavor.

This speaks heavily in favor of making `now` return local time, as 
opposed to UTC.


I think it can be argued that local time is of far more relevance to 
most users than UTC.

Should someone come up with any use case that needs access to the 
current time in UTC, then possible workarounds would be:

- for the user to hard-code time zone offset into their scene file;

- for the user to design the scene such that time zone offset can be 
passed via `Declare=` INI file setting;

- for us to provide some `timezone` pre-defined variable that evaluates 
to the time zone offset in days, ready to be subtracted from `now` to 
give UTC, or a `utc()` function that converts from local time to UTC. (I 
would lean towards the latter, as the former variable would not be in 
the common format of hours, which might give rise to confusion.)


> I guess I see a place for a hard coded 'now' UTC/Z result - and as 
> accurate an internal time/timer as we can get (is your fix at odds with 
> timer use?).

I'm not sure what you mean by "at odds with timer use".

What I can say is that the fix does not compromise timer precision, if 
that's what you mean.


> Aside 1: A reminder that in newer(to be v4.0) code, you moved 'now' off 
> boost completely. This is in fact is the code povr uses - meaning any 
> unix/linux 'bug' is in that code too.

Actually, no - in this case `now` returning local time is not a 
Unix/Linux bug (or, more to the point, not a "boost on Unix/Linux bug"), 
but rather proper intrinsic behavior of the new implementation I chose.

I realize only now that I accidently implemented the wrong behavior 
(judging by the documentation, and intent so far).

It's not the worst of accidents though. I'd like to consider it a Bob 
Ross moment.


> Aside 2: The Parse_Datetime() code has too that use of:
> 
> setlocale(LC_TIME,"");
> 
> the full implications of which made me a little nervous along with the 
> etting being afterward persistent.

You and me both, bro.

> So after the strftime() call I added:
> 
> setlocale(LC_TIME,"C");

Without any additional safety net, that would actually be 
counter-productive: `setlocale` is not thread-safe; so if we ever run 
multiple parser threads in parallel, and they come across the same piece 
of code nearly at the same time, your "cleanup" could throw the other 
thread off the rails.

The good news is that the above call only sets the time-specific 
portions of the locale, which we don't mess with anywhere else. So 
ideally we should call `setlocale(LC_TIME,"")` somewhere on program 
startup, and never look back.


> (a) Lying some. Unsure what might happen with the boost variant over the 
> pure c++11 one for now, but the latter didn't account for daylight 
> savings adjustments which also makes datetime(), %z and %Z less than 
> precisely useful.

The v4.0 variant doesn't respect daylight savings zone? Yikes!

That'll be another problem to solve then.

Post a reply to this message

On 2021-07-30 2:29 PM (-4), clipka wrote:
> 
> - When users see a date or time, they will usually expect it to indicate
> local time. To achieve that, the parameter passed to `datetime()` would
> have to be of local time flavor.
> 
> This speaks heavily in favor of making `now` return local time, as
> opposed to UTC.
> 
> 
> I think it can be argued that local time is of far more relevance to
> most users than UTC.
> 
> [snip]
> 
> Actually, no - in this case `now` returning local time is not a
> Unix/Linux bug (or, more to the point, not a "boost on Unix/Linux bug"),
> but rather proper intrinsic behavior of the new implementation I chose.
> 
> 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
box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
in behavior?

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
> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
> in behavior?

I think I do, yes.

The current behavior appears to be quite inconsistent across platforms 
and systems and whatnot.

Post a reply to this message

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
>> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
>> 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:
> 
>   v3.8 default -> 2021-07-28 08:11:16Z
> 
> 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

Le 2021-07-30 à 19:13, clipka a écrit :
> 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
>> box, it (pre-beta) does return UTC or GMT.  Are you proposing a change
>> 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")
returns the current local time with an extraneous «Z» appended at the end.
Running the Windows version under Windows 10.

The default formatting string do end with «%SZ». I think that it should 
end with «%S%Z».

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:

> //---
>    #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>

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.


>    #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.

Should it though?
The C (and by extension C++) standard mandates that `strftime` replace 
`%c` with "the locale’s appropriate date and time representation". 
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 
>   set up all the fields needed to use the complete set of 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?

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 
> `%c` with "the locale’s appropriate date and time representation". 
> 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   set up all the fields needed to use the complete set of 
>> 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