uutils/coreutils · error

setting date not implemented (unsupported target)

Error message

setting date not implemented (unsupported target)

What it means

A Rust `unimplemented!()` panic compiled into uu_date only when the target is neither `unix` nor `windows`. `set_system_datetime()` is what `date --set=...` / `date -s ...` calls (src/uu/date/src/date.rs:389-390); supported targets use `clock_settime` (unix, src/uu/date/src/date.rs:1251) or `SetSystemTime` (windows, src/uu/date/src/date.rs:1270), while macOS and Redox deliberately return a graceful `USimpleError` (src/uu/date/src/date.rs:1230,1238). The catch-all stub predates that graceful pattern, so on exotic targets `--set` aborts the process with a panic instead of printing an error.

Source

Thrown at src/uu/date/src/date.rs:1217

fn get_clock_resolution() -> Timestamp {
    // Redox OS does not support the posix clock_getres function, however
    // internally it uses a resolution of 1ns to represent timestamps.
    // https://gitlab.redox-os.org/redox-os/kernel/-/blob/master/src/time.rs
    Timestamp::constant(0, 1)
}

#[cfg(windows)]
fn get_clock_resolution() -> Timestamp {
    // Windows does not expose a system call for getting the resolution of the
    // clock, however the FILETIME struct returned by GetSystemTimeAsFileTime,
    // and GetSystemTimePreciseAsFileTime has a resolution of 100ns.
    // https://learn.microsoft.com/en-us/windows/win32/api/minwinbase/ns-minwinbase-filetime
    Timestamp::constant(0, 100)
}

#[cfg(not(any(unix, windows)))]
fn set_system_datetime(_date: Zoned) -> UResult<()> {
    unimplemented!("setting date not implemented (unsupported target)");
}

/// Convert a parsed date for the system clock.
fn convert_for_set(date: Zoned, utc: bool) -> Zoned {
    if utc {
        date.timestamp().to_zoned(TimeZone::UTC)
    } else {
        date
    }
}

#[cfg(target_os = "macos")]
fn set_system_datetime(_date: Zoned) -> UResult<()> {
    Err(USimpleError::new(
        1,
        translate!("date-error-setting-date-not-supported-macos"),
    ))
}

View on GitHub (pinned to 2c9a666674)

Solutions

1. If you do not need `--set` on that target, exclude or ignore the flag (don't run `date -s`) - every other date feature works.
2. Patch the stub to mirror the macOS/Redox pattern and return `USimpleError::new(1, translate!("date-error-setting-date-not-supported-..."))` instead of `unimplemented!()`, then upstream it (the repo's rule: a PR needs a test in tests/by-util/test_date.rs).
3. Implement `set_system_datetime` for your target with its native 'set system clock' syscall, following the rustix `clock_settime` shape at src/uu/date/src/date.rs:1251.
4. As a library consumer, call `std::panic::catch_unwind` around any uu_date entry point that may reach `--set`, and check the payload string.

Example fix

// before (src/uu/date/src/date.rs:1215-1218)
#[cfg(not(any(unix, windows)))]
fn set_system_datetime(_date: Zoned) -> UResult<()> {
    unimplemented!("setting date not implemented (unsupported target)");
}

// after - same graceful-error pattern the macOS and Redox arms already use
#[cfg(not(any(unix, windows)))]
fn set_system_datetime(_date: Zoned) -> UResult<()> {
    Err(USimpleError::new(
        1,
        translate!("date-error-setting-date-not-supported"),
    ))
}

// Gate the --set code path before it reaches the stub (src/uu/date/src/date.rs:389)
#[cfg(not(any(unix, windows)))]
fn can_set_system_datetime() -> bool {
    false // only the unimplemented!() stub is compiled on this target
}
#[cfg(any(unix, windows))]
fn can_set_system_datetime() -> bool {
    true
}

if settings.set_to.is_some() && !can_set_system_datetime() {
    return Err(USimpleError::new(1, "date: setting the date is not supported on this target"));
}

fn supports_setting_date() -> bool {
    cfg!(any(unix, windows))
}

use std::panic;

// set_system_datetime returns UResult, but the unsupported-target stub panics
let outcome = panic::catch_unwind(|| set_system_datetime(convert_for_set(date, utc)));
match outcome {
    Ok(result) => result?,
    Err(payload) => {
        let msg = payload.downcast_ref::<String>().map(String::as_str);
        if msg.is_some_and(|m| m.contains("not implemented")) {
            eprintln!("date: --set unsupported on this target");
            std::process::exit(1);
        }
        std::panic::resume_unwind(payload);
    }
}

When it happens

Trigger: Compile the `date` binary for any target without `cfg(unix)`/`cfg(windows)` (wasm, bare-metal, custom OS ports) and run it with `--set=DATE` or `-s DATE`; the Some(date) branch at src/uu/date/src/date.rs:389 calls this stub directly and panics with exit code 101.

Common situations: Vendors cross-compiling uutils/coreutils to wasm or embedded/niche OSes; container/sandbox images built for unusual triples that still run config scripts; test harnesses that exercise every flag of the binary on a non-standard host. Linux/macOS/BSD/Windows users never hit it because a real implementation or graceful error is compiled instead.

Related errors

• getting clock resolution not implemented (unsupported target
• not implemented

AI-assisted analysis of uutils/coreutils@2c9a666674 (2026-08-16). Data as JSON: /api/errors/4778b980263f6ce3. Report an issue: GitHub.