uutils/coreutils · error

getting clock resolution not implemented (unsupported target

Error message

getting clock resolution not implemented (unsupported target)

What it means

This is a Rust `unimplemented!()` panic, not a recoverable error. uutils' `date` reimplementation selects `get_clock_resolution()` via `#[cfg]`: a rustix `clock_getres` version for unix (src/uu/date/src/date.rs:1189), a fixed 100ns constant for windows, and this panic stub for every other target. The function backs the `--resolution` flag (DateSource::Resolution, src/uu/date/src/date.rs:555-556), so on a target that is neither `unix` nor `windows` the process panics with exit code 101 as soon as that code path is compiled in and reached.

Source

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

                            "date: warning: using midnight as starting time: 00:00:00"
                        );
                    }
                }
            }
            Ok(ParsedDateTime::InRange(result))
        }
        Ok(ParsedDateTime::Extended(date)) if allow_extended => Ok(ParsedDateTime::Extended(date)),
        Ok(ParsedDateTime::Extended(_)) => Err((
            input_str.into(),
            parse_datetime::ParseDateTimeError::InvalidInput,
        )),
        Err(e) => Err((input_str.into(), e)),
    }
}

#[cfg(not(any(unix, windows)))]
fn get_clock_resolution() -> Timestamp {
    unimplemented!("getting clock resolution not implemented (unsupported target)");
}

#[cfg(all(unix, not(target_os = "redox")))]
/// Returns the resolution of the system’s realtime clock.
///
/// # Panics
///
/// Panics if `clock_getres` fails. On a POSIX-compliant system this should not occur,
/// as `CLOCK_REALTIME` is required to be supported.
/// Failure would indicate a non-conforming or otherwise broken implementation.
fn get_clock_resolution() -> Timestamp {
    use rustix::time::{ClockId, clock_getres};

    let timespec = clock_getres(ClockId::Realtime);

    #[allow(clippy::unnecessary_cast, reason = "needed for 32 bit target")]
    Timestamp::constant(timespec.tv_sec as _, timespec.tv_nsec as _)
}

View on GitHub (pinned to 2c9a666674)

Solutions

1. Run `cargo check --target <your-target>` and grep the build for which `get_clock_resolution` arm compiled; if your target is not unix/windows, either switch to a supported target or stop shipping the `--resolution` flag for it.
2. Patch the stub to fail gracefully like the macOS/Redox `set_system_datetime` branches do (return a UResult error instead of panicking) so callers see a normal CLI error instead of a panic.
3. Implement the function for your target using its native clock API (the unix arm at src/uu/date/src/date.rs:1189 shows the rustix `clock_getres` pattern; Windows shows the hardcoded-resolution fallback) and upstream it.
4. If you are embedding uu_date as a library, wrap the call in `std::panic::catch_unwind` and treat a panic payload containing "getting clock resolution not implemented" as 'unsupported'.

Example fix

// before (src/uu/date/src/date.rs:1176-1179)
#[cfg(not(any(unix, windows)))]
fn get_clock_resolution() -> Timestamp {
    unimplemented!("getting clock resolution not implemented (unsupported target)");
}

// after - fail like the macOS/Redox set_system_datetime branches, not by panicking
#[cfg(not(any(unix, windows)))]
fn get_clock_resolution() -> UResult<Timestamp> {
    Err(USimpleError::new(
        1,
        translate!("date-error-clock-resolution-not-supported"),
    ))
}
// callers: let resolution = get_clock_resolution()?;  (src/uu/date/src/date.rs:556)

// Decide before shipping/calling: this target has no get_clock_resolution impl
#[cfg(any(unix, windows))]
const SUPPORTS_CLOCK_RESOLUTION: bool = true;
#[cfg(not(any(unix, windows)))]
const SUPPORTS_CLOCK_RESOLUTION: bool = false;

if !SUPPORTS_CLOCK_RESOLUTION {
    eprintln!("date: --resolution is not supported on this target");
    std::process::exit(1);
}
let resolution = get_clock_resolution(); // src/uu/date/src/date.rs:556

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

use std::panic;

let attempt = panic::catch_unwind(get_clock_resolution);
let resolution = match attempt {
    Ok(ts) => ts,
    Err(payload) => {
        let msg = payload
            .downcast_ref::<String>()
            .map(String::as_str)
            .or_else(|| payload.downcast_ref::<&str>().copied())
            .unwrap_or("panic");
        if msg.contains("not implemented") {
            // unsupported target: degrade, don't crash the caller
            Timestamp::constant(0, 1)
        } else {
            std::panic::resume_unwind(payload);
        }
    }
};

When it happens

Trigger: Building the `date` binary (or the uu_date crate) for a target where neither `cfg(unix)` nor `cfg(windows)` holds - e.g. wasm32-unknown-unknown, wasm32-wasi, or a bare-metal/embedded target - and then invoking it with `--resolution` (parsed into DateSource::Resolution at src/uu/date/src/date.rs:555, which calls get_clock_resolution() unconditionally).

Common situations: Cross-compiling uutils/coreutils to wasm or an embedded OS for size/API experiments; a distro or vendor porting uutils to a niche OS inheriting the stub; contributors running the full flag surface in tests on an exotic host. On mainstream linux/macos/bsd/windows the stub is never compiled, so the panic only surprises non-standard target users.

Related errors

• setting date not implemented (unsupported target)
• not implemented

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