c# - 有没有C#静态分析工具可以抓取不满足功能需求的API？

Question

我最大的烦恼之一是 API 的功能与普通用户的直觉不符。

切入点:.NET 的 DateTime.ToUniversalTime .文档很吓人:

On Windows XP systems, the ToUniversalTime method recognizes only the current adjustment rule when converting from local time to UTC. As a result, conversions for periods before the current adjustment rule came into effect may not accurately reflect the difference between local time and UTC.

然后继续说:

On Windows XP systems, the ToUniversalTime method recognizes only the current adjustment rule for the local time zone, which it applies to all dates, including down-level dates (that is, dates that are earlier than the starting date of the current adjustment rule). Applications running on Windows XP that require historically accurate local date and time calculations must work around this behavior by using the FindSystemTimeZoneById method to retrieve a TimeZoneInfo object that corresponds to the local time zone and calling its TimeZoneInfo.ConvertTimeToUtc(DateTime, TimeZoneInfo) method.

这一定是有史以来最搞笑的文档句子。谁在使用 ToUniversalTime() 时不需要准确的本地日期和时间计算？为什么不使用 ObsoleteAttribute 标记此方法？

无论如何，我正在寻找的是一个可以用程序集级元数据标记程序集的工具，例如 [RequiresHistoricallyAccurateLocalDateAndTimeCalculationsAttribute]。然后，如果它找到任何 ToUniversalTime() 实例，将它们标记为编译器错误，就像 C# 不允许我在没有不安全注释的情况下直接访问非托管代码一样。

Answer 1

这个需求似乎更适合代码分析而不是属性修饰或者编译错误。

参见:http://www.binarycoder.net/fxcop/html/index.html

This has to be the single most hilarious sentence of documentation ever created. Who doesn't require accurate local date and time calculations when using ToUniversalTime()? Why not just mark this method with ObsoleteAttribute?

鉴于日期/时间计算的性质/复杂性，这并不是一个特别可怕/令人震惊的启示。

如果我在 Windows XP 或任何其他操作系统上进行 UTC 处理，我会首先熟悉该平台的特性，就像我了解几乎所有其他复杂操作一样。给出的替代方案 (TimeZoneInfo) 也不是万无一失的，因为它高度依赖于平台。

关于 TimeZoneInfo 的平台依赖性......我指的是操作系统。

当您开始使用时区转换(许多与日期相关的问题都源于此)时，您会使用类似 FindSystemTimeZoneById 的方法.从好的方面来说，方法名称清楚地表明您正在使用本地系统(因此它可能比 ToUniversalTime() 更明确)。但是，操作系统会查询时区列表，因此操作系统可能会返回一个错误列表(我相信 Windows 中的值存在于注册表中)，该列表已过时(可能是一台打补丁的机器)等

我注意到 Windows XP 似乎也有 ambiguity TimeZoneInfo 的问题(请参阅“调用者注意事项”):

On Windows XP systems (...) As a result, the method may not accurately report ambiguous time offsets for periods before the current adjustment rule came into effect. For more information, see the Notes for Callers section in the Local property.

并且(正如您所指出的)底层平台实现可能存在缺陷。

此外，时区由字符串 ID 引用。虽然这些似乎没有太大变化，但仍然有可能在应用程序中存储不再匹配时区的“魔术字符串”。

至少这是我所发现的，尽管我对这个主题的了解远非详尽无遗。我在 Windows Server 上使用 .Net 和世界时的经验是积极的。

我的观点是，BCL(基类库)作者以某种方式实现事物通常有充分的理由，即使它确实导致了意外行为。另一种方法是完全省略该功能。

如果您认为这是一个陷阱，那么我认为值得称赞的是您花时间来缓解它。