假设我们有一个 WCF 服务,它接受一些 DateTime
对象并使用它,并且我们有一个以 dd/mm/yyyy
格式发送它的客户端。但是这个服务也是从 JS 调用的,它应该发送准确的 DateTime
,这就是它使用 yyyy-MM-ddTHH:mm:ss.fffzzz
格式的原因。
是否可以创建一个采用两种格式的文化,并且不写像 if (DateTime.TryParse(format1, out dt) || DateTime.TryParse( format2, out dt) || DateTime.TryParse(format3, out dt) || ...)
此代码的另一个缺点是我们还必须为 DateTimeOffset
复制它
最佳答案
这就是 ASP.NET MVC 处理该问题的方式。我认为同样的原则也适用于使用 WCF 等其他技术实现的服务。这些约定由 Web 服务使用。
ASP.NET MVC(包括 Web API)对查询字符串中传递的参数执行不区分区域性的解析。因此,URL 中的日期必须采用通用格式 yyyy-mm-dd。表单值(或请求正文中的任何值)应采用服务器指定的格式。这意味着设置为英国文化的服务器将期望日期采用英国日期格式:dd-mm-yyyy。
为什么对 URL 中的项目执行不区分区域性的解析?
对 URL 中的项目执行区域性不敏感的解析有一个非常好的、合乎逻辑且方便的理由。想象一下,我看到一件商品正在促销,并且促销的 URL 中包含 from
和 to
日期。如果我通过电子邮件将该链接发送给我在德国的 friend (我住在加拿大),我希望他们看到相同的页面。如果对 URL 中的日期执行文化敏感的解析,我的 friend 可能会看到完全不同的销售,或者可能会看到找不到页面 - 这不会很好。
因此,为了回答您的问题,调用 WCF 服务的客户端应以服务指定的格式向您的服务提供日期,除非日期位于 URL 中,在这种情况下,客户端应以通用格式 yyyy- 提供日期月-日。
另一个选项是客户端向服务提供区域性(例如,在 SOAP header 中),并且服务在解析时将使用该区域性。
关于c# - 具有多种日期时间表示形式的 CultureInfo,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/41348323/