.NET的“ U”（通用完整）DateTime格式说明符的用例是什么？

Question

（前言：尽管这个问题一定是主观的，但它既不打算过于宽泛也不基于观点）。

我正在跟踪软件中的一个错误，该错误使用了dtValue.ToString( "U", CultureInfo.InvariantCulture )而不是dtValue.ToString( "u", CultureInfo.InvariantCulture )。

（我想这是因为"R"和"r"以及"O"和"o"在字母大小写上不同，.NET对待它们的方式相同，而{{1 }}和"U"代表了截然不同的格式和行为。

解决此问题后，我查看了t he documentation for the U format out of curiosity，并质疑它为什么首先存在，因为我无法想到"u"的用例。

对于那些想知道的人：U是这样做的：

1. 如果它是一个U值，那么总是会抛出一个DateTimeOffset。
2. 如果值为FormatException，则在内部使用DateTime将其转换为UTC：
   • 如果DateTime.ToUniversalTime，则不进行任何转换。
   • 如果使用value.Kind == DateTimeKind.Utc或value.Kind == DateTimeKind.Local，则应用本地计算机的系统时区的当前UTC偏移量将其转换为UTC。
3. 然后，使用特定于区域性的Unspecified格式（"F"）格式化该值。
   • DateTimeFormatInfo.FullDateTimePattern使用InvariantCulture。
   • "dddd, dd MMMM yyyy HH:mm:ss"使用en-US。
   • "dddd, MMMM d, yyyy h:mm:ss tt"使用en-GB。

我的推理：

• 由于格式是特定于区域性的，因此不能用于机器对机器的通信。
  • 当然，除非您使用"dd MMMM yyyy HH:mm:ss"，但是结果输出字符串具有冗余信息（日期名称）并且难以解析信息（英语全月名称），而机器可读格式始终使用以下形式ISO 8601的InvariantCulture。
• 转换中的信息丢失，例如本地时间或本地UTC偏移量。
• 通常程序将在不考虑yyyy-MM-dd HH:mm[:ss][zzz]的情况下处理不同的DateTime值（例如，使用DateTimeKind值的程序就好像它代表了UTC，尤其是在本地计算机的时区为UTC时）或英国时间（因此您会在英国夏季时间遇到一些有趣的错误）。
  • 因此，如果您要转到DateTimeKind.Local或在switch上分支以明确转换为UTC，则可以使用dtValue.Kind并避免使用F的隐式UTC转换。
  • 我期望U格式为DateTimeKind.Unspecified的值会引发异常，因为该值的偏移量是 unspecified -令人惊讶的是，U使用本地计算机时区的当前值偏移量（与ToUniversalTime()一样），而不是抱怨进行假设。 （不过，这就是为什么我们应该尽可能使用Local或NodaTime的原因。）
• DateTimeOffset根本不支持它（大概是为了让.NET程序员放弃使用它？）。

我的问题：

“您是否曾经有意使用DateTimeOffset格式说明符或在生产代码中使用过它？为什么？在当时是个好主意，还是一个不错的选择？”