-
Notifications
You must be signed in to change notification settings - Fork 152
-
Notifications
You must be signed in to change notification settings - Fork 152
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
timestamp formatting bug #329
Comments
We recently upgraded to 2.0.2 and never saw this on 1.6.2, so I'm wondering if 6ac18e6 might be the problematic change. It does not seem like there have been any other substantive changes to the timestamp formatting logic since 1.6.2. |
Thanks for reporting this! I will try to have a look and reproduce it over the next few days |
Could it have to do with using |
Ah, never mind–we use |
I tried to reproduce the issue, but unfortunately, I couldn't. However, I'm feeling confident that the changes made in the pull request at https://github.com/odygrd/quill/pull/336/files will likely fix it. |
Could you backport this fix to earlier versions? Upgrading to the latest version is not something we can necessarily do right now due to the many |
Which version do you need patched? |
Could you do it for 2.0.2? |
I have made one here https://github.com/odygrd/quill/releases/tag/v2.0.3 |
Probably you are already aware of it but I just wanted to let you know. It is possible to build quill with an external libfmt version. You can have installed an older fmt version on your system and the logger should work. Line 8 in 7612b4a
|
We are occasionally seeing timestamps at midnight–that is, when the time is in the range
[00:00:00, 00:00:01)
–with the hour component as 24 instead of 0. Looking at the code inquill/include/quill/detail/backend/StringFromTime.h
andquill/src/detail/backend/StringFromTime.cpp
, it was not immediately obvious to me how this could happen, though the inconsistent nature of this issue suggests that the caching logic is likely the culprit. I tried to craft a test that would reproduce this behavior, but was unable to do so. Below is a sequence of timestamps for which this happened:Our timestamp format is
"%Y%m%dT%H:%M:%S.%Qns"
.The text was updated successfully, but these errors were encountered: