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