fix: change the format of the ascTime() function

[airween]

what

This PR changes the format of utils::string::ascTime().

The function is used only in one place, in transaction.cc, it produces the field time_stamp if the audit log format is JSON, for eg.:

{"transaction":{"client_ip":"200.249.12.31","time_stamp":"Sat Jun 07 11:46:23 2025"}}

why

The old (actual) format of that function is %c, which is the expected format, but as the documentation writes:

writes standard date and time string, e.g. Sun Oct 17 04:41:13 2010 (locale dependent)

it's locale dependent. This means if the locale uses only 1 digit for the day, then the test is failed, see this comment. The log in that case will look like this:

{"transaction":{"client_ip":"200.249.12.31","time_stamp":"Sat Jun  7 11:46:23 2025"}}

Please note that there are two spaces and 1 digit.

This modification changes the format and if the day is below 10, then adds a leading zero, without extra space.

references

C++ reference of strftime.

other notes

Please review this PR carefully as it may break audit log file JSON parsers if the server localization uses a single-digit date representation.

[airween]

@JakubOnderka could you take a review too?

[theseion]

I was confused as to why this fix is necessary, so I looked into the LLVM implementation. It turns out that the use %a %b %e %T %Y (%e instead of %c) but just use a fixed size for the output string:
https://github.com/llvm/llvm-project/blob/995d74f8663edb2e20f2d2672556582a6f4cc3f1/libc/src/time/strftime_core/composite_converter.h#L180. That explains the additional space.

[airween]

so I looked into the LLVM implementation.

Thanks for reviewing that.

Moreover, your suggestion to %T makes sense, this escaped my attention, thanks too.

Unfortunately, after my initial commit the error still persists, even on Linux (with gcc).

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[airween]

Hmm... all test have passed. It's very weird.

Note, that the original problem was (in my opinion) that previously the test expected this format: \S{3} \S{3} \d{2}, but yesterday the output was Sat Jun 7, which didn't match.