log: improve timestamps on stderr log output

[mkemel]

This adds date and milliseconds to the timestamp output to stderr-full, and also adds timestamp to stderr log output

[mkemel@lptp systemd]$ sudo hirte-agent -c ~/hirte-conf/agent.conf
2023-06-12 08:56:46,331+0300 DEBUG	: Final configuration used
2023-06-12 08:56:46,332+0300 DEBUG	: Connected to system bus
2023-06-12 08:56:46,332+0300 DEBUG	: Connected to systemd bus
2023-06-12 08:56:46,336+0300 INFO	: Connecting to manager on tcp:host=127.0.0.1,port=842
2023-06-12 08:56:46,337+0300 INFO	: Connected to manager as 'laptop'

[engelmi]

I am not sure if logging the date provides much value since stderr-full is - usually - used for local development etc. and with journal logging we get the date anyway. The milliseconds might be pretty useful for developing, though.

[rhatdan]

@mkemel What is going on with this PR?

[mkemel]

So now it's a full timestamp including timezone
2023-06-12 08:56:46,331+0300 DEBUG : Final configuration used
I thought how to test that, but since the expected output of the function is dependent on the timezone setting of the machine it's running on, I couldn't think of a way to test that without assembling the expected output exactly the way it is done in the tested function, which doesn't test much.
Any ideas? Or just skip unit test for that one?

[engelmi]

So now it's a full timestamp including timezone 2023-06-12 08:56:46,331+0300 DEBUG : Final configuration used I thought how to test that, but since the expected output of the function is dependent on the timezone setting of the machine it's running on, I couldn't think of a way to test that without assembling the expected output exactly the way it is done in the tested function, which doesn't test much. Any ideas? Or just skip unit test for that one?

Basically make the time format function testable by passing the time struct to it like Martin described here:
#321 (comment)
This way also does only one thing (formatting), adhering to srp, and not two.

[mkemel]

@engelmi That's what I did, but time struct does not have timezone info.
In any case, I looked at it again now, and I see that there's a function that returns Greenwich time struct for a given time struct so that might help

[mkemel]

We are not talking about struct tm, which does include timezone info, but has only seconds resolution. We use struct timespec.
Now I see that I can alter the timestamp function to have a flag to show Greenwich time. This is not very useful except for testing purposes, but it won't hurt

[mkemel]

Okay, all done including tests

[mkemel]

Integration test failure is unrelated

[engelmi]

LGTM
Thanks for adding unit tests!

[pypingou]

Any ideas? Or just skip unit test for that one?

Set the timezone for the test using an environment variable?