settimeofday() 需 root 权限或 CAP_SYS_TIME 能力，普通用户调用返回 -1 且 errno=EPERM；需 sudo 运行或 setcap 授权，且须停用 systemd-timesyncd 等时间同步服务以防覆盖。
settimeofday() 需要 root 权限，普通用户调用会失败
直接调用 settimeofday() 设置系统时间在 Linux 下一定会返回 -1，errno 为 EPERM。这不是代码写错了，而是内核强制限制：只有具备 CAP_SYS_TIME 能力（通常等价于 root）的进程才能修改系统时钟。
常见错误现象：
- 程序编译运行无报错，但时间没变，
gettimeofday()读出来还是旧值 - 检查
return值发现是 -1，perror("settimeofday")输出Operation not permitted
实操建议：
- 必须用
sudo启动程序，例如sudo ./settime - 或者给二进制文件显式授予权限：
sudo setcap cap_sys_time+ep ./settime（比始终用 sudo 更安全） - 注意：容器环境（如 Docker）默认不带
CAP_SYS_TIME，需加--cap-add=SYS_TIME
struct timeval 和 struct timezone 的填值要点
settimeofday() 第一个参数是 const struct timeval*，第二个是 const struct timezone*；后者在现代 Linux 中已被废弃，传 nullptr 即可，否则可能触发警告或意外行为。
立即学习“C++免费学习笔记（深入）”；
关键细节：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
tv_sec是自 Unix epoch（1970-01-01 00:00:00 UTC）以来的秒数，不是本地时区秒数 -
tv_usec是微秒部分，范围必须是[0, 999999]；超出会截断或导致 EINVAL - 不要手算本地时间戳——用
mktime()+localtime()容易出时区偏差；推荐用timegm()（输入 UTC 时间）或直接从 NTP 服务解析后的time_t
示例片段：
struct timeval tv = { .tv_sec = 1724085900, .tv_usec = 123456 };
settimeofday(&tv, nullptr); // 第二个参数必须为 nullptr
systemd-timesyncd 或 chronyd 运行时，手动设时间会被覆盖
如果系统启用了 systemd-timesyncd、chronyd 或 ntpd，它们会在几秒到几分钟内检测到“时间跳变”，并强行把系统时间拉回（尤其当偏移 > 0.128s 时）。你刚设完，立刻 date 查看可能还是旧值。
应对方式取决于使用场景：
- 临时调试：先停掉时间同步服务，
sudo systemctl stop systemd-timesyncd（或chronyd） - 生产环境：不要手动设时间，改用
timedatectl set-time "YYYY-MM-DD HH:MM:SS"，它会协调服务状态 - 若必须用 C++ 控制，设完后调用
clock_adjtime(CLOCK_REALTIME, &adj)做渐进式校准（避免跳变），但逻辑更复杂
clock_settime(CLOCK_REALTIME, ...) 和 settimeofday() 选哪个？
两者都能设系统时间，但行为有差异：
-
settimeofday()是传统接口，接受struct timeval，语义清晰，兼容性最好（所有 Linux 内核都支持） -
clock_settime(CLOCK_REALTIME, ...)接受struct timespec（纳秒精度），POSIX 标准，但某些老内核或嵌入式环境可能未完全实现 - 性能上无差别；功能上
clock_settime支持更多时钟源（如CLOCK_TAI），但设系统时间时二者等价
建议优先用 settimeofday()：参数更直观，出错路径少，调试信息更明确。除非你已经在用 timespec 处理高精度时间，否则没必要切换。
真正容易被忽略的是权限与服务冲突这两层——代码能编译、能跑、甚至返回 0，不代表时间真的改成功了。务必验证：date -u 看 UTC 时间，再确认对应服务是否仍在后台重置它。
