Am 12.08.2021 um 14:16 schrieb William F Pokorny:

> A now_for_datetime can be sloppy to the order most concerns we've 
> pointed out are OK. It could always use the local machine's epoch and 
> local setting - aligning with other local tools in the machine/OS 
> environment. Something easier for users to use date time wise.

Um - nope.

Juging from my experience with trying to get the `datetime` and `now` 
stuff sorted out, a `now` based on local time will only be a source of 
utter confusion.

What would that value even represent?

The only sensible formulation is a "time units since D-Day H-Hour".

Such a D-Day H-Hour would have well-defined DST semantics, either 
explicitly by definition or implicitly by user expectation. If D-Day was 
2000-01-01, H-Hour was 00:00, and the value was advertised as local 
time, then users would expect H-Hour to imply local non-DST in the 
northern hemisphere, local DST in the southern hemisphre, or non-DST if 
their time zone does not observe DST at all.

So if some user were to compute a point in time of, say, 2000-07-01 
00:00 local time - would that be D-Day H-Hour plus exactly 182*24 hours, 
or 1 hour more or less due to DST?


That won't fly. Not in the "easier for the user" sort of way, at any rate.

And certainly not in the "easier for the programmer" sort of way either, 
that much I can guarantee already.


> Imagine a large, long running, parser characterization job for all the 
> 'things' for which we want to track relative performance. The 
> information from which we, perhaps, stick in a big table via jr's new 
> macro and publish. Regular timing results useful to users and developers.

And that will be utterly useless if the functionality to actually 
implement the timing measurements takes considerable time compared to 
what we actually want to measure.

For such an endeavor, things need to have the lightest footprint in 
parser itself that we can possibly create. Ideally, it would just be a 
single (and possibly even very short) token. What that statement would 
trigger can be a bit more complex, because it will be compiled, rather 
than having to be parsed.

Possibly a job for a dedicated build, that adds a single-character token 
just for the purpose, and which isn't functional in release builds. "@" 
isn't used anywhere, for example.

This could trigger one or more performance metrics to be logged whenever 
"@" is encountered, and the result dumped once parsing (or rendering) 
has completed. Maybe a fixed number of characters to follow (say, 4), to 
be logged along with it. The resulting dump could then be correlated 
with the scene later.

If you want precise results, that would be the road to give you the most 
reliable data.

Post a reply to this message