我看了一下 cppreference.org （重点是我的）：
时钟
std::chrono::utc_clock是表示协调世界时 (UTC) 的时钟。它从 1970 年 1 月 1 日星期四 00:00:00 UTC 开始测量时间，包括闰秒。
将其与 的定义进行比较system_clock：
system_clock测量 Unix 时间（即，自 1970 年 1 月 1 日星期四 00:00:00 协调世界时 (UTC) 开始的时间，不包括闰秒）。
是否真的可以在同一个系统中拥有两者？例如，如果系统时钟通过 NTP 同步，则服务器决定现在是什么时间，这可能使用闰秒或不使用闰秒，但 C++ 库实现对此一无所知。或者，在引入闰秒时，该标准是否需要数据库？
NTP 服务器为您提供 UTC（以 seconds-since-1900 格式）。当前时间，是当前时间。为了到达那里，有多少闰秒并不重要。
事情变得复杂的地方是添加了闰秒。NTP 将在此刻宣布这一点，并且各种操作系统在内部做各种事情来记录这一点，因为它们倾向于将时间存储为“自一个纪元以来的秒数”——Linux 和 Windows 不包括闰秒，因为这会使他们的时间戳渲染更加复杂（有多少闰秒？）并且他们无法处理。相反，他们只是在宣布的闰秒前后稍微减慢或加快时钟，因此他们并没有实际记录它，而是调整自己的秒数，以便将该计数作为时间戳呈现在以后会显得准确。
（我不知道的是，操作系统如何在不知道要扣除多少闰秒的情况下从 NTP 事务中重新确定它的非真正但排序的秒数；欢迎编辑。）
system_clock给你这个秒数，它（在主流平台上）直接来自操作系统（例如time()）。
utc_clock给你一个类似的秒数，但一个是“真实的”。在这样的主流平台上，这必然是system_clock事后添加的闰秒。这些历史数据也来自系统，实际上是某种数据库（尽管确切的来源取决于实现）。
总之，两个时钟的数据源（略有）不同，因此它们是否可以在同一个系统上共存是毫无疑问的。但是，这system_clock 可能直接来自您的操作系统，而这utc_clock 可能不是。
我找到了这个关于 C++ 20 时间的工作草案，它似乎应该在公元 2020 年发布。它有一个关于 utc_clock的子页面，其中包括这个例子：
clock_cast<utc_clock>(sys_seconds{sys_days{1970y/January/1}}).time_since_epoch() is 0s.
clock_cast<utc_clock>(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()
并声明最后一个值“是 946'684'822s，即 10'957 * 86'400s + 22s。” 请注意，10,957 天大约是 30 年，因此 utc_clock 的值显然表示自 1970 年 1 月 1 日 UTC 以来的秒数，其中每个闰秒都会增加 utc_clock 的值。
由于这表示为转换，因此推断转换将调用闰秒表似乎是合理的，并且即使操作系统没有 UTC 和 TAI 之间区别的概念，也没有分钟的概念，也可以执行该转换其中包含 61 秒。
我必须承认我对时间比 C++ 更感兴趣，并且近 20 年没有写过严肃的 C++ 代码。