Allow configuration to omit timestamp from current log file name when rolling logs by date

[Ryaningli]

Feature Request

Crates

tracing-appender

Motivation

I am currently using tracing-appender for log rotation in my project. When logs rotate based on date, the current active log file includes the timestamp in its filename, resulting in filenames like app.log.2025-09-28.

However, for better readability and usability, I would like the option to configure the rollover so that the current active log file does not include the timestamp, but only the base filename, e.g., app.log, and older log files retain the timestamp, such as app.log.2025-09-27, app.log.2025-09-26, etc.

Proposal

Introduce a configuration option in RollingFileAppender::builder to allow users to specify whether the current log file should include the timestamp in its filename during rotation. This could be achieved by adding a new method, such as with_current_log_filename_with_timestamp, which defaults to true. When set to false, the current active log file would be named simply app.log, while older log files would continue to have timestamps, e.g., app.log.2025-09-27.

Example configuration:

use tracing::subscriber;
use tracing_appender::rolling::{Rotation, RollingFileAppender};
use tracing_subscriber::fmt;

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let dir = "logs";
    let filename_prefix = "app.log";

    let appender = RollingFileAppender::builder()
        .max_log_files(7)
        .rotation(Rotation::DAILY)
        .filename_prefix(filename_prefix)
        .with_current_log_filename_with_timestamp(false) // TODO: Consider a better method name
        .build(dir)
        .map_err(|e| format!("Failed to build logging appender: {}", e))?;

    let (non_blocking, _guard) = tracing_appender::non_blocking(appender);

    let subscriber = fmt::Subscriber::builder()
        .with_writer(non_blocking)
        .pretty()
        .finish();

    subscriber::set_global_default(subscriber).expect("setting default subscriber failed");

    Ok(())
}

Alternatives

There are currently no particularly elegant alternatives.

---

If the proposed solution is feasible or if there is a better approach to meet this requirement, I would be happy to submit a PR to implement the change.