- 主题:设计标准库时间类的人脑子里到底怎么想的？
如果有夏时制，或跨时区计算时间怎么办？
如在美国的铁路列车时刻表。
所以，基础时间变量只能以格林威治时间为准，以某个时间原点为起点，按一定时间粒度计量的一个整数。所有的时间点都采用这个坐标系计算。最后，转换为你习惯的格式显示出来。
【 在 finlab 的大作中提到: 】
: duration_cast<duration<double, milli>>(endTime - startTime).count())
: 直接加个方法：(endTime - startTime).milli_seconds() 这样不好吗？
: 又不会弄混单位，写起来也简单。
: ...................
--
修改:ylh0315 FROM 221.221.52.*
FROM 221.221.52.*
是的。
我是铁路的，时间计算是经常的。就是你说的这个道理。
润秒可以忽略。
但是GPS就不能忽略了。
我们就是使用这样一种时间计算库来计算复杂的时间算法。
【 在 poggy 的大作中提到: 】
:
: 我觉得其实就是一层抽象， 通过抽象， 屏蔽了不同时钟体系的差异，
: 最主要的一个差异就是， 闰年和闰秒的存在， 一个简单的例子，2001年减去1998年，
: ...................
--
FROM 221.218.60.*
可以。startTime与endTime可以以任何粒度表示。内部统一转换为纳秒序列，运算完毕统一转换为结果粒度。
【 在 finlab 的大作中提到: 】
: duration_cast<duration<double, milli>>(endTime - startTime).count())
: 直接加个方法：(endTime - startTime).milli_seconds() 这样不好吗？
: 又不会弄混单位，写起来也简单。
: ...................
--
FROM 221.218.60.*