On 8/8/21 6:54 PM, clipka wrote:
> We have established that the `datetime(now)` combo is both currently 
> broken (on some systems), and has some shortcomings in its design (on 
> all systems, both broken and otherwise).
> 
> 
> I think the key issues in finding any satisfactory solution are the 
> following:
...

Suppose I'd lean toward (C.2) with (A.1) for what you've proposed.

FWIW.
----
In June I worked some on datetime() to support an internal always local 
clock now, but as importantly to make work the %z and %Z formatting 
options whether the fractional days were coming from now or being 
generated on the fly. The last bit, I failed initially to recall on 
mentioning the trailing 'Z' with a non utc time result.

Beyond the initial changes, I had plans for a new f_clock() internal 
function. Admittedly, my aim was in part to insulate povr from whatever 
'now' was doing, but there were additional reasons. Due your post, I've 
worked up an initial version of f_clock() much earlier than planned to 
test how crazy my plans were and to help clarify my thoughts.

---
In your preamble, you didn't mention 'now' being used as an SDL timing 
mechanism. It's something people do today and it carries risk with 
respect to any particular timing result. The reasons is we are using the 
system_clock for 'now' which can be updated at any time moving forward 
or backward - synchronization with time servers, etc.

We don't warn against timing use of 'now' in the documentation as far as 
I know. Perhaps we should?

In povr's f_clock() the up front returned time comes from steady_clock 
instead - which on my Ubuntu 20.04 machine appears to be a monotonic 
clock since the last reboot/boot.

Suppose the following povr SDL:

//---
#declare Fn_TimePt00 = function (sec_in_day) { now*sec_in_day }
#declare TimePt00 = f_clock(0,0,0);
#debug concat("f_clock(0,0,0) ",str(f_clock(0,0,0),9,9),"\n")
#for (I,0,3000000,1)
     #declare Dummy = 1.0;
#end
#declare Fn_TimePt01 = function (sec_in_day) { now*sec_in_day }
#declare TimePt01 = f_clock(0,0,0);
#debug concat("f_clock(0,0,0) ",str(f_clock(0,0,0),9,9),"\n")

#debug "\n"
#declare SecInDay = (24*60*60);
#debug concat("Fn_TimePt00 ",str(Fn_TimePt00(SecInDay),9,9),"\n")
#debug concat("Fn_TimePt01 ",str(Fn_TimePt01(SecInDay),9,9),"\n")
#debug concat("Fn_TimePt01 - Fn_TimePt00 ",
     str(Fn_TimePt01(SecInDay)-Fn_TimePt00(SecInDay),9,9),"\n")

#debug "\n"

#debug concat("TimePt00 ",str(TimePt00,9,9),"\n")
#debug concat("TimePt01 ",str(TimePt01,9,9),"\n")
#debug concat("TimePt01 - TimePt00 ",
     str(TimePt01-TimePt00,9,9),"\n")
#debug "\n"

#error "Parsing test. Stop early."
//---

The povr branch generates:

f_clock(0,0,0) 234835.462146713
Parsing 17764K tokens
f_clock(0,0,0) 234838.496408219

Fn_TimePt00 681978977.077232242
Fn_TimePt01 681978980.111495137
Fn_TimePt01 - Fn_TimePt00 3.034262896

TimePt00 234835.462139445
TimePt01 234838.496401535
TimePt01 - TimePt00 3.034262090

Of note for POV-Ray v3.8 and onward is that the Fn_TimePt00, Fn_TimePt00 
method for capturing time points should work in v3.8 beta 1, but it 
doesn't because when 'now' was added, the support for it was not added 
to parser_strings.cpp alongside pi, tau, etc. This a stand alone 'now' 
issue.

The other current return types from f_clock() are:

1 - Whole seconds to system wall clock since Y2K.
2 - Fractional days to system wall clock since Y2K (The povr 'now').
3 - Difference between machine epoch and y2k epoch in seconds.
4 - Convert local seconds since machine epoch to utc.

The second argument is whether to account for dst, or not, for types 1,2,3.

The third and last argument is the local seconds argument for return 
type utc. The method for this turned out uglier than hoped, though it 
appears to work.

I don't consider the form of f_clock final - in povr, as often as not, 
just trying outs ideas. A type to directly return seconds since machine 
epoch might be nice. Maybe other stuff. We'll see.

---
Putting more of the whole plan/implementation on the table because I see 
secondary 'concerns' such as POV-Ray's Y2K epoch not lining up with any 
unix like system I've ever used - all have been at Jan 1, 1970. This 
makes understanding the values POV-Ray is generating and using harder to 
work with.

Unix commands like date have some nice options:

date --date='TZ="America/Los_Angeles" 09:00 next Mon' +"%s"

but we cannot use the results directly in POV-Ray. Hmm, maybe an 
explicit unix time to y2k seconds type for f_clock...

---
I'll end with my view our 'now' is trying to be both a timer and a 
time/date input and I'm not sure these are completely compatible. Most 
of the time/date stuff which works for dst uses only seconds resolution 
as far as I know(1).

---
Aside:
Supposing datetime fixed to support %z %Z, and 'now' returning always a 
no dst utc or local time you can fairly easily adjust the fractional day 
value to account for dst of say an hour with:

#declare DSToffset = (1/24);

#debug concat("now + (1/24) ",
datetime(now+DSToffset,"%Y-%m-%d %H:%M:%S %z"),"\n")

#debug concat("now + (1/24) ",
datetime(now+DSToffset,"%Y-%m-%d %H:%M:%S %Z"),"\n")

FWIW.

Bill P.

(1) - The C++/Boost (plus time.h etc) date/time options go on forever. I 
don't begin to understand them all and it looks like c++20 is aiming to 
revamp/extend a lot of it. Coding wise. I tried to stick mostly with c.

Post a reply to this message