我最大的烦恼之一就是API不会像普通用户那样直截了当地做API。
Case-in-point：.NET的DateTime.ToUniversalTime。文档令人恐惧：
在Windows XP系统上，ToUniversalTime方法仅在从本地时间转换为UTC时识别当前调整规则。因此，在当前调整规则生效之前的时段的转换可能无法准确反映本地时间与UTC之间的差异。
后来继续说：
在Windows XP系统上，ToUniversalTime方法仅识别本地时区的当前调整规则，该规则适用于所有日期，包括下级日期（即早于当前日期的日期）调整规则）。 在Windows XP上运行的需要历史上准确的本地日期和时间计算的应用程序必须解决此问题，方法是使用FindSystemTimeZoneById方法检索与本地时区对应的TimeZoneInfo对象并调用其TimeZoneInfo.ConvertTimeToUtc（ DateTime，TimeZoneInfo）方法。
这必须是有史以来最热闹的文档句子。使用ToUniversalTime（）时，谁不需要准确的本地日期和时间计算？为什么不用ObsoleteAttribute标记此方法？
无论如何，我正在寻找的是一个工具，我可以用汇编级元数据标记汇编，例如[RequiresHistoricallyAccurateLocalDateAndTimeCalculationsAttribute]。然后，如果它找到ToUniversalTime（）的任何实例，则将它们标记为编译器错误，就像C＃不允许我直接访问非托管代码而没有不安全的注释一样。
答案 0 :(得分：3)
此要求似乎更适合代码分析，而不是属性修饰或编译错误。
请参阅：http://www.binarycoder.net/fxcop/html/index.html
这必须是单个最热闹的文档句子 曾经创造过。谁不需要准确的当地日期和时间 使用ToUniversalTime（）时的计算？为什么不标记这个 使用ObsoleteAttribute的方法？
鉴于日期/时间计算的性质/复杂性，这不是一个特别可怕/令人震惊的启示。
如果我在Windows XP或任何其他操作系统上进行UTC处理，我首先会熟悉平台的特性，就像我几乎任何其他复杂的操作一样。给定的替代方法（TimeZoneInfo）也不是防弹的，因为它高度依赖于平台。
关于TimeZoneInfo的平台依赖性......我指的是操作系统。
当您开始使用时区转换（许多与日期相关的问题源自此时）时，您使用FindSystemTimeZoneById之类的方法。从好的方面来说，方法名称清楚地表明您正在使用本地系统（因此它可能不像ToUniversalTime()那样含糊不清）。但是，系统会查询操作系统的时区列表，因此操作系统可能会返回错误的列表（我相信Windows中的值存在于注册表中），列表过时（可能是修补过的机器） ）等等。
我注意到Windows XP似乎与TimeZoneInfo存在ambiguity问题（请参阅“来电者注意事项”）：
在Windows XP系统上（...）因此，该方法可能无法准确报告模糊时间 在当前调整规则出现之前的时段的偏移量 影响。有关详细信息，请参阅中的“调用者注释”部分 当地财产。
并且（正如您所指出的），底层平台实施可能存在缺陷。
此外，时区由字符串ID引用。虽然这些似乎没有太大变化，但仍有可能存储在不再与时区匹配的应用程序中的“魔术字符串”。
至少那是我发现的，虽然我对这个主题的了解远非详尽无遗。我在Windows Server上使用.Net和通用时间的经验是积极的。
我的观点是，BCL（基类库）作者通常有一个很好的理由以某种方式实现事物，即使 导致意外行为。另一种方法是完全省略功能。
如果你认为这是一个陷阱，那么我认为你花时间来减轻它是值得称道的。
答案 1 :(得分：1)
使用FxCop工具与自己交朋友。据我所知，这就是你要找的东西。它是一个静态分析工具，可以使用表示为依赖于FxCop API的C＃代码的自定义规则进行扩展。