DateTimeOffset的Ticks在夏令时场景下为何出现排序矛盾？

这不是bug，是DateTimeOffset.Ticks属性的定义特性导致的——它返回的是对象中本地时间（DateTime属性）的刻度数，而非UTC时间的刻度数。

结合你提供的调试数据具体分析：

• kvpPrevious.Key：2020-11-01 01:55:00 -04:00，属于夏令时结束前的本地时间，对应UTC时间为2020-11-01 05:55:00。它的Ticks值（0x08d87e0924323200）是本地时间2020-11-01 01:55:00的刻度数。
• kvpCurrent.Key：2020-11-01 01:00:00 -05:00，这是夏令时回拨后的本地时间（此时时钟从凌晨2点倒回1点，这个1点是当天第二次出现），对应UTC时间为2020-11-01 06:00:00。它的Ticks值（0x08d87e01753e2800）是本地时间2020-11-01 01:00:00的刻度数。

从本地时间维度看，01:55确实晚于01:00，所以前者的Ticks数值更大；但SortedList<DateTimeOffset, Something>的排序逻辑是基于DateTimeOffset的比较规则——直接对比两个对象对应的UTC时间。由于05:55 UTC早于06:00 UTC，所以kvpPrevious会排在kvpCurrent前面，这完全符合你“按UTC时间正确排序”的预期。

简言之：DateTimeOffset.Ticks反映本地时间刻度，而DateTimeOffset的排序依据UTC时间，两者逻辑不同，因此出现“排序在前的对象Ticks更大”的情况是正常现象，并非bug。

内容的提问来源于stack exchange，提问作者Eric Ouellet