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