前言
bmc_time组件本身不"生产"时间，只搬运NTP或RTC时间，因此时间不准确或跳变等问题**99%**不是组件问题。
注意：不要习惯性地直接认为组件有问题。
1. 高频问题
1.1 为什么BMC时间每次重启后都会恢复到1970年
时间戳的起点是1970-01-01T00:00:00，1表示在这个时间的基础上过去了1秒。
复位后，BMC没有时间戳，因此显示为1970年。获取到时间戳后才会恢复正常。
1.2 为什么有时间跳变
时间跳变分为以下几种情况：
1.2.1 1970的跳变
这是正常现象，原因如上所述。
1.2.2 复位后1970跳变到一个时间，过了一会又会跳变一次
为了保证服务启动后尽早使用"相对有效"的时间戳，而不是1970，系统会将复位前的时间戳持久化下来，复位后先暂时使用。
持久化的触发时机为：
- 刚启动时持久化一次
- 每天自动持久化一次
- 时间跳变时持久化一次
- 平滑重启时持久化一次
因此，像强制重启等操作，可能出现持久化时间戳较旧的情况，因为没有机会去持久化当前最新的时间戳。
此场景会有app日志：set bmc_time time_stamp=%s by persistent data
1.2.3 时间源跳变
首先检查NTP是否开启，NTP开启后只从NTP读取时间：
ipmcget -d ntp如果Status为enabled说明已开启，Synchronize表示是否同步成功。
这又分为两种情况：
- NTP同步成功后产生的跳变：说明RTC和NTP时间不一致，需要自行排查RTC和NTP哪个有问题。
- NTP一直开启，突然跳变：说明是NTP服务器的问题。
如果NTP未开启，则查看RTC芯片的时间，只要BMC和RTC芯片时间一致，则联系硬件定位。
**方式一：**OS侧执行hwclock查看OS时间，一般情况下和BMC是一致的，不一致则看方式二。
**方式二：**读寄存器，一般是CpuBoard，如果不是则换成对应的读取格式。
命令：
mdbctl call Smc_CpuBrdSMC_010101 bmc.kepler.Chip.BlockIO Read 0 201327872 8解析说明：例如 133.7.1.8.3.6.16.26 → 100+133+7*256年 1月8日 6:16:26
年份固定+100：RTC时钟在SMC中存储时以1800年起始，Linux系统tm结构设置时间从1900年开始算。
1.3 date -s 设置命令后又变回去
首先明确一个基本常识：
正常情况下，BMC会从时间源周期性同步准确时间，时间源为NTP或RTC。
因此，修改本地时间后过一会就会被刷新回去。
date -s是Linux系统自带命令，不是组件提供的。
需要确认系统使用的时间源：
ipmcget -d ntp：查看NTP是否开启hwclock：在OS侧查看RTC时间
如果时间不符合预期，联系对应的责任人。
2. 接口设置类
2.1 设置NTP地址获取模式AddressMode失败
查询网络模块是否开启对应的DHCP地址模式。若未开启自动获取模式，则需先开启，再修改NTP地址获取模式，否则将修改失败。
2.2 IPMITool标准命令设置时间失败
格式要求：%m/%d/%Y %H:%M:%S
示例：
ipmitool sel time set "06/13/2025 08:35:00"NTP开启场景会报错：Command not supported in present state
3. 时间查询类
3.1 NTP不能同步
NTP服务的连通由开源软件处理，bmc_time本身不处理，因此出现异常问题时可以先自行查询相关资料。
- 在环境中查看设置的IP是否为有效的NTP服务器IP：
/usr/sbin/ntpdate -uD ip下图所示为无效IP：
- 若为有效IP，则查看IP是否写进对应配置文件：
/data/trust/ntp/ntp.conf
说明：开启NTP后，会写入配置文件，如果没写入才需要排查代码是否有问题。
- 查看NTP服务器状态：
ntpq -c as只有显示sys.peer时该NTP服务器可信。
- 在V2环境的IP可以，V3就不行：
确认IP和端口都是通的，这种情况只能是环境问题，例如大网小网的问题。