-
-
Notifications
You must be signed in to change notification settings - Fork 174
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
Daily rollover uses UTC instead of local time #213
Comments
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for reporting the issue. |
Hey, bot, this issue is not stale! :) |
Wait, why is this issue closed? Is it fixed? |
Any updates on this? Im experiencing the same problem for quite a while. |
I found a solution. use FileNamePattern: "%d{yyyy.MM.dd, " + TimeZone.getDefault().getID() + "}" |
@enuoCM This only works when you programmatically set the pattern, right? I'm using a logback.xml which doesn't seem to evaluate "TimeZone.getDefault().getID()". Commit 446eb7c probably has caused this issue. It sets the timezone to "GMT" if no timezone is given instead of doing the simple "super()" call. |
The scheme worked. I tried it out.I am from China, so this is my use of software to translate Chinese into English, which may be difficult to read.Above this code directly into XML as if not, use a plus sign to the connection string, should be used in the Java code, rather than in XML, so I will call in the Java code TimeZone.getDefault().getID() to get the time zone id in my area, so that it can be hard code written in XML, so weakness is hard-coded, as I have the following code is only suitable for time zones in China mobile phone use: |
Dont set GMT+0 timezone in RollingCalendar if no timezone is given (fixes #213)
Description
I configured daily rollover with TimeBasedRollingPolicy, according to example in wiki. It generally works, but rollover happens at UTC midnight, not local midnight. This may be confusing.
I know it's possible to specify time zone explicitly, but I suppose local time should be used by default, like it was in older versions (e.g. 1.1.1).
Maybe the same issue was reported at #198.
Steps to reproduce
Environment
logback-android
version: 2.0.0The text was updated successfully, but these errors were encountered: