Timestamp is incorrect when milliseconds < 100 #156
Description
There's a bug which only occurs when milliseconds are less than 100:
<131>1 2021-09-27T15:52:34.137-07:00 localhost test-graylog-syslog 103039 - - error: Test error message, without stack trace
<131>1 2021-09-27T15:52:35.35-07:00 localhost test-graylog-syslog 103065 - - error: Test error message, without stack trace
15:52:35.35 should be 15:52:35.035. As-is it will probably get interpreted as 15:52:35.350 (I know Graylog does this, for instance).
Interestingly enough, this bug is mentioned directly in the RFC5424 spec:
The TIMESTAMP described in Section 6.2.3 supports fractional seconds.
This provides grounds for a very common coding error, where leading
zeros are removed from the fractional seconds. For example, the
TIMESTAMP "2003-10-11T22:13:14.003" may be erroneously written as
"2003-10-11T22:13:14.3". This would indicate 300 milliseconds
instead of the 3 milliseconds actually meant.
(https://datatracker.ietf.org/doc/html/rfc5424#appendix-A.4)
This is a bug in the glossy dependency. The one used by this library hasn't been updated since 2016 and hasn't seen a release since 2014. However, there's a fork that includes a fix for this as well as at least one other issue (#139):