以下是我在 C# 中使用的设置的一些片段:
设置.settings
<Setting Name="SomeSettingUtcDate" Type="System.DateTime" Scope="Application">
<Value Profile="(Default)">10/27/2014 12:00:00</Value>
</Setting>
Settings.Designer.cs
[global::System.Configuration.ApplicationScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
[global::System.Configuration.DefaultSettingValueAttribute("11/6/2014 12:00:00")]
public global::System.DateTime SomeSettingUtcDate {
get {
return ((global::System.DateTime)(this["SomeSettingUtcDate"]));
}
}
正如您从名称中看到的，我希望日期采用 UTC 时间。在我的用例中，接受日期的方法将通过检查 DateTime.Kind 属性并确保它是 来检查传递给它的日期是否为 UTC。 DateTimeKind.Utc。但是，通过调用 Settings.Default.SomeSettingUtcDate 返回的日期将不会设置此属性。
为了满足调用方法中的检查，创建一个具有 UTC 类型集的新 DateTime 对象似乎是一种黑客行为，因为使用 UTC 日期的大部分目的是让每个人都知道就事情何时真正发生达成一致，并促使人们思考时间并在第一时间就把事情做好。如果我们从设置文件中获取任何旧的日期值并假设它毕竟是 UTC，那么在我看来，我们也可以不检查 Kind 是否为 Utc，因为设置文件中不必如此。
由于我的方法可以使用另一个日期(而不是设置文件中的日期)调用，因此检查 UTC 类型仍然有值(value)，所以我如何才能缩小这一差距并使我和其他开发人员更容易“落入成功的深渊”，日期存储在设置文件中？
有没有办法通过不同的日期时间对象指定 UTC(因此至少日期被假定为 UTC，并且在编辑设置时在 GUI 中明显显示一些指示符，例如它是例如 UtcDateTime)，或者在日期字符串本身中指定 UTC？
最佳答案
Kind 未在设置文件中序列化，因此反序列化时无法取回它。最好的选择可能是使用 DateTimeOffset 而不是 DateTime； DateTimeOffset 嵌入时区信息，该信息包含在其字符串表示形式中，因此如果序列化 UTC 日期，则反序列化时将获得 UTC 日期。
(注意:DateTimeOffset 不会出现在设置设计器的类型下拉列表中，因此您必须从列表末尾的“浏览...”条目中手动选择它；它位于 mscorlib/System 下)
关于c# - 将 UTC 日期存储在 Visual Studio 设置文件中，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/26790529/