关于SystemTime::now()的疑问：delayed_now是否可能大于new_now？

我编写了如下Rust代码：

use std::time::{Duration, SystemTime};
use std::thread::sleep;

fn main() {
    let now = SystemTime::now();
    let delayed_now = now + Duration::from_secs(10);
  
    let x = delayed_now.duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs()
        - now.duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs();
   
    let sleep_time = Duration::from_secs(x);
   
    sleep(sleep_time);
   
    let new_now = SystemTime::now();
    if delayed_now > new_now {
        println!("ohno");
    }
}

我想知道在排除闰秒场景的前提下，delayed_now是否有可能大于new_now？我在Playground运行代码并未触发该条件，但我认为由于纳秒信息丢失，这种情况应该是可能的，却无法验证。

回答 #

是的，这种情况确实有可能发生，核心原因是时间精度丢失和系统调度的不确定性：

• SystemTime::now()获取的时间点包含纳秒级精度，但通过duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs()转换时，会直接丢弃纳秒部分，只保留整秒数值。
• 举个具体场景：假设now的实际时间是1600000000秒 + 500000000纳秒（即1600000000.5秒），那么delayed_now就是1600000010秒 + 500000000纳秒（1600000010.5秒）。
• 计算x时，delayed_now转成整秒是1600000010，now转成整秒是1600000000，因此x=10，最终sleep_time是10整秒。
• 调用sleep(sleep_time)时，系统仅保证休眠时长至少10秒，但实际结束时间可能是1600000010秒 + 300000000纳秒（1600000010.3秒）——这可能是系统调度延迟、时钟精度限制或其他进程抢占资源导致的。
• 此时delayed_now（1600000010.5秒）会明显大于new_now（1600000010.3秒），触发println!("ohno")的逻辑。

你在Playground中未触发该情况，是因为Playground的运行环境负载低、调度稳定，纳秒级的时间差很难出现。但在真实生产环境中，尤其是系统资源紧张时，这种场景完全可能发生。

内容的提问来源于stack exchange，提问作者nz_21