Skip to content
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

logs are not showing correct time after Chile DST time change #2943

Open
Raghu-icon opened this issue Sep 11, 2024 · 7 comments
Open

logs are not showing correct time after Chile DST time change #2943

Raghu-icon opened this issue Sep 11, 2024 · 7 comments
Labels
bug Incorrect, unexpected, or unintended behavior of existing code

Comments

@Raghu-icon
Copy link

Description

After DST time change in Chile , the logs are not showing the correct time with plain %d date pattern on September 8th but after midnight of 9th September the logs are printing correct date without having to change anything
but when we use date format with time zone it shows correct date on 8th September also .

Configuration

Version: 2.24

Operating system: RHEL

JDK: openJDK17

Logs

[Stacktraces, errors, etc. relevant applications logs.]

Reproduction

[An isolated test reproducing the test.
JUnit tests similar to the ones in the code base are extremely appreciated.]

Here’s the steps to reproduce it:

  1. Set the date on the server to September 8, with the time any time after 2am.
  2. Use a plain %d date format in log4j config file .

Here is the java code and config file :
import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.util.TimeZone;

public class SimpleLog4jExample {

// Create a logger instance
private static final Logger logger = LogManager.getLogger(SimpleLog4jExample.class);

public static void main(String[] args) {
    // Log messages of different levels
     String tzid = "America/Santiago";
   // tzid = readln("Enter time zone ID [" + tzid + "]: ", tzid);
    TimeZone tz = TimeZone.getTimeZone(tzid);
    TimeZone.setDefault(tz);
    logger.info("This is an info message");
    logger.warn("This is a warning message");
    logger.error("This is an error message");
}

}

log4j2.xml

@ppkarwasz
Copy link
Contributor

@Raghu-icon,

This is probably a JDK or operating system update problem. Do you have the latest version of JDK 17? Some countries have stable daylight saving time rules and the JDK and operating system know them for years in advance. Other countries decide the dates of the change between winter and summer time at the last moment and you need for that data to be included in the JDK and OS.

@Raghu-icon
Copy link
Author

Raghu-icon commented Sep 11, 2024

@ppkarwasz Thank you for the response .
When we print the time in Java program / date command in RHEL both shows correct the date with DST change , but the log timestamp is incorrect .
Additionally when we use the date format , its showing correct date .

@ppkarwasz
Copy link
Contributor

Can you show us your configuration file?

@Raghu-icon
Copy link
Author

Raghu-icon commented Sep 11, 2024

<?xml version="1.0" encoding="UTF-8"?>
<Configuration status="WARN">
    <Appenders>
        <Console name="Console" target="SYSTEM_OUT">
            <PatternLayout pattern="%d %-5p %c{1}:%L - %m%n"/>
        </Console>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="Console"/>
        </Root>
    </Loggers>
</Configuration>

@ppkarwasz
Copy link
Contributor

@Raghu-icon,

When you use %d Log4j uses a very performant FixedDateFormatter, which computes the "date" part of a timestamp only once a day and caches it. The class is DST-aware and thoroughly tested, but we might have missed some edge case. Can you tell us:

  • The exact day and hour DST started in Chile this year?
  • Which part of the timestamp was wrong: did the "date" part fail to be updated when DST started or did the "time" part fail to switch?

Even better, could your provide a test case? The test cases for America/Chicago are in FixedDateFormatter.

@ppkarwasz ppkarwasz added the bug Incorrect, unexpected, or unintended behavior of existing code label Sep 11, 2024
@Raghu-icon
Copy link
Author

Raghu-icon commented Sep 12, 2024

  1. Chile DST changes were applied on 8th September 2024 00:00 hours .
  2. The timestamp part was incorrect on 8th September , its still uses earlier timestamp , and importantly this issue is only on 8th September , once the time reached to 9th September 00:00 hours , it automatically started printing correct timestamp accounting the DST .

As of now I have this simple java class to reproduce the issue . Please note to reproduce this you have to change the system date / time to 8th September midnight to 9th September midnight .
If you require test case I may need some time . Thanks you !

import org.apache.logging.log4j.LogManager;
import org.apache.logging.log4j.Logger;
import java.util.TimeZone;

public class SimpleLog4jExample {

// Create a logger instance
private static final Logger logger = LogManager.getLogger(SimpleLog4jExample.class);

public static void main(String[] args) {
    // Log messages of different levels
     String tzid = "America/Santiago";
   // tzid = readln("Enter time zone ID [" + tzid + "]: ", tzid);
    TimeZone tz = TimeZone.getTimeZone(tzid);
    TimeZone.setDefault(tz);
    logger.info("This is an info message");
    logger.warn("This is a warning message");
    logger.error("This is an error message");
}

@ppkarwasz
Copy link
Contributor

I confirmed the bug using two additional test cases in our FixedDateFormatTest:

static Stream<Arguments> testDaylightSaving() {
return Stream.of(
// DST start
Arguments.of(
US_CENTRAL_DATA_SPRING,
ZoneId.of("US/Central"),
LocalDateTime.of(2017, Month.MARCH, 12, 0, 0)
.atZone(ZoneOffset.UTC)
.toInstant()),
Arguments.of(
CHILE_DATA_SPRING,
ZoneId.of("America/Santiago"),
LocalDateTime.of(2019, Month.SEPTEMBER, 8, 3, 0)
.atZone(ZoneOffset.UTC)
.toInstant()),
// DST end
Arguments.of(
US_CENTRAL_DATA_FALL,
ZoneId.of("US/Central"),
LocalDateTime.of(2017, Month.NOVEMBER, 5, 0, 0)
.atZone(ZoneOffset.UTC)
.toInstant()),
Arguments.of(
CHILE_DATA_FALL,
ZoneId.of("America/Santiago"),
LocalDateTime.of(2019, Month.APRIL, 6, 2, 0)
.atZone(ZoneOffset.UTC)
.toInstant()));
}

The modified test is available in the fix/2.x/2943_dst_on_midnight branch. We have quite a lot on our TODO list right now, but we'll try to dig into it before the next DST change.

We are of course happy if someone can provide a PR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Incorrect, unexpected, or unintended behavior of existing code
Projects
None yet
Development

No branches or pull requests

2 participants