How to define timezone in mariadb testcontainer accessed via r2dbc:tc:mariadb

[aabeling]

I am able to start a mariadb testcontainer with a jdbc url like r2dbc:tc:mariadb:///workflow?TC_IMAGE_TAG=10.6.21.
But it does not have the correct timezone I need for my application and my tests.
Tests for queries using NOW() make problems.

With jdbc:tc:mysql:8.0.36://hostname/databasename?TC_MY_CNF=somepath/mysql_conf_override it is possible to provide a my.cnf with something like

[mysqld]
default-time-zone = "Europe/Berlin"

The same is possible with jdbc:tc:mariadb.

How can I set the timezone for the database container with "r2dbc"?

#4687 says it does not support TC_INITSCRIPT, but this would not help to set the timezone anyway since the timezone must be defined at the start of the database server.

[Nickalus12]

[aabeling]

No, this did not work for me.

I did not even find any mentioning of TC_ENV or TC_COMMAND in this repository.

I can confirm that the environment variable TZ can be used to change the timezone of a mariadb container. I tested that by running a mariadb container without testcontainers by a simple "docker run mariadb" with appropriate environment variables.

I debugged through the testcontainers code and was able to "docker inspect" the container started by testcontainers.
While the "native" mariadb container showed the environment variable "TZ", the container started by testcontainers did not.

Further debugging showed that during initialization org.testcontainers.r2dbc.TestcontainersR2DBCConnectionFactory#create and org.testcontainers.containers.MariaDBR2DBCDatabaseContainerProvider#createContainer is used.
This code does not contain any handling of "TC_ENV" settings although they are contained in the ConnectionFactoryOptions.

During debugging I was able to overwrite org.testcontainers.containers.ContainerDef#envVars of the created container with TZ=Europe/Berlin before start of the container. This started the container with the expected timezone.

Can you please point me to the code, where the application of TC_ENV_TZ should happen?

[qa-ashutosh]

Hi @aabeling

You've actually done the hard diagnostic work already, you confirmed TZ works on the container and traced it to MariaDBR2DBCDatabaseContainerProvider#createContainer not forwarding TC_ENV options from ConnectionFactoryOptions. That is a genuine gap in the R2DBC URL-based container setup.

The most reliable workaround right now is to bypass the URL-based container creation entirely and instantiate the MariaDBContainer programmatically, which gives you full control over environment variables before startup. You can then wire it into your Spring context via @DynamicPropertySource:

@Testcontainers
@SpringBootTest
class YourIntegrationTest {

    @Container
    static MariaDBContainer<?> mariaDB = new MariaDBContainer<>("mariadb:10.6.21")
            .withDatabaseName("workflow")
            .withUsername("test")
            .withPassword("test")
            .withEnv("TZ", "Europe/Berlin");  // this is the key line

    @DynamicPropertySource
    static void registerProperties(DynamicPropertyRegistry registry) {
        registry.add("spring.r2dbc.url", () ->
            String.format("r2dbc:mariadb://%s:%d/%s",
                mariaDB.getHost(),
                mariaDB.getMappedPort(3306),
                mariaDB.getDatabaseName()
            )
        );
        registry.add("spring.r2dbc.username", mariaDB::getUsername);
        registry.add("spring.r2dbc.password", mariaDB::getPassword);
    }
}

This works because withEnv() on the container instance sets the Docker environment variable before the container starts, which is exactly what you confirmed works when running docker run mariadb manually with TZ set.

If you want to keep the URL-based approach, there is a second option, use the MariaDB R2DBC connector's own timezone parameter, which was introduced in connector version 1.2.0. This sets the timezone at the connection level rather than the server level:

r2dbc:tc:mariadb:///workflow?TC_IMAGE_TAG=10.6.21&timezone=Europe/Berlin

The values it accepts are auto (uses JVM default), a named timezone like Europe/Berlin, or an offset like +01:00. This won't change what NOW() returns at the database server level but does align the connection's timezone interpretation, whether that's sufficient depends on your exact use case with NOW().

For your specific scenario where NOW() results need to match a server-side timezone, the programmatic withEnv("TZ", ...) approach is the correct fix. The URL-based TC_ENV support for R2DBC is the underlying gap, worth raising as a bug or feature request on the Testcontainers repo if you haven't already, since your debugging already pinpointed exactly where the fix needs to go in MariaDBR2DBCDatabaseContainerProvider.

[MILLERMARRU]

The R2DBC URL provider (MariaDBR2DBCDatabaseContainerProvider) does not forward TC_MY_CNF or TC_ENV options from the connection URL - those are only processed by the JDBC provider. The cleanest workaround is to create the container programmatically and then build the R2DBC connection factory pointing to it:

@Container
static MariaDBContainer<?> mariadb = new MariaDBContainer<>("mariadb:10.6.21")
    .withEnv("TZ", "Europe/Berlin")
    .withCommand("--default-time-zone=Europe/Berlin");

Then configure your R2DBC connection factory using the container's host and mapped port instead of the r2dbc:tc: URL:

ConnectionFactory connectionFactory = ConnectionFactories.get(
    ConnectionFactoryOptions.builder()
        .option(DRIVER, "mariadb")
        .option(HOST, mariadb.getHost())
        .option(PORT, mariadb.getMappedPort(3306))
        .option(DATABASE, "workflow")
        .option(USER, mariadb.getUsername())
        .option(PASSWORD, mariadb.getPassword())
        .build()
);

The --default-time-zone server option ensures NOW() returns values in Europe/Berlin regardless of the client session timezone. The TZ env var sets the OS timezone for the container process as a complement.

If you prefer keeping the r2dbc:tc: URL, you can subclass MariaDBR2DBCDatabaseContainerProvider and override createContainer to apply the env var - but the programmatic approach above is simpler and fully supported.