如果有夏时制，或跨时区计算时间怎么办？
如在美国的铁路列车时刻表。
所以，基础时间变量只能以格林威治时间为准，以某个时间原点为起点，按一定时间粒度计量的一个整数。所有的时间点都采用这个坐标系计算。最后，转换为你习惯的格式显示出来。
【 在 finlab 的大作中提到: 】
: duration_cast<duration<double, milli>>(endTime - startTime).count())
: 直接加个方法：(endTime - startTime).milli_seconds() 这样不好吗？
: 又不会弄混单位，写起来也简单。
: ...................
--
修改:ylh0315 FROM 221.221.52.*
FROM 221.221.52.*

【 在 ylh0315 的大作中提到: 】
: 如果有夏时制，或跨时区计算时间怎么办？
: 如在美国的铁路列车时刻表。
: 所以，基础时间变量只能以格林威治时间为准，以某个时间原点为起点，按一定时间粒度计量的一个整数。所有的时间点都采用这个坐标系计算。最后，转换为你习惯的格式显示出来。

我觉得其实就是一层抽象， 通过抽象， 屏蔽了不同时钟体系的差异，
最主要的一个差异就是， 闰年和闰秒的存在， 一个简单的例子，2001年减去1998年，
年的粒度下是3， 但是天的粒度下，没有办法直接3*365来得到天数，同理，
由于闰秒的存在， 同样的， 如果间隔是3分钟， 同样不能简单的得到180秒的结论。
闰年取决于使用的日历，那么润秒呢? 取决于所选用的时钟，
这个格林威治的世界时钟， 和滴答不停的原子时钟是不一样的。还有我们C++库里面经常使用UNIX时间，
Unix 时间戳是从1970年1月1日（UTC/GMT的午夜）开始所经过的秒数，其实这个也是不考虑闰秒的。
换句话说， 我们回到1970年1月1日， 并开启一个原子时钟计时， 你用原子时钟计时得到的秒数，和调用UNXI时间函数返回来的是不一样的，因此，离开时钟，谈间隔，是会犯错误的。

而这个类库，则帮我们做了这些抽象，是我们不需要理解这么复杂的东西。
当然，现实是， 作为一个C++程序员， 小到一个字符编码， 数字精度表示， 大到一个系统，还都得弄懂。
--
FROM 124.126.3.*

这是为了统一风格的
--
FROM 119.161.171.*

C++标准委员会的人脑子不进水的话，当年就没JAVA什么事了。
--
FROM 101.88.159.*

概念一直很清楚，你说的那么多的不是时间，时间点和时间段都是绝对的，时间粒度秒也是绝对定义的。

你纠结那么多的是墙上时间，是给人看的，相当于各种诡异的 printf 格式， 不用展示的话完全不用去考虑。

【 在 poggy 的大作中提到: 】
:
: 【 在 ylh0315 的大作中提到: 】
: : 如果有夏时制，或跨时区计算时间怎么办？
: : 如在美国的铁路列车时刻表。
: : 所以，基础时间变量只能以格林威治时间为准，以某个时间原点为起点，按一定时间粒度计量的一个整数。所有的时间点都采用这个坐标系计算。最后，转换为你习惯的格式显示出来。


#发自zSMTH-v-@钛星
--
FROM 222.129.52.*