【问题标题】:Sending date-only fields to browser apps将仅日期字段发送到浏览器应用程序
【发布时间】:2015-12-15 20:07:09
【问题描述】:

我正在创建一个基于浏览器的单页应用程序,它将从我控制的 API 中以 JSON 格式检索信息。 API 通常会返回大型、复杂的对象图(对象中的对象等)。许多对象包含“仅日期字段”(即仅与日期相关的字段) - 也就是说,如果一个字段设置为“2015 年 4 月 1 日”,它应该始终向用户显示为 4 月 1 日,无论用户的时区、夏令时等。当然,API 服务器的时区应该对显示的日期没有影响(并且可以假定永远固定)。

在服务器端 API 代码中,我可以轻松识别这些“仅日期字段”,并在将它们发送到客户端之前以任何方式对它们进行预处理。

在客户端,这些日期将以多种方式使用(显示在文本框和标签中,传递给 AngularJS 的“日期”过滤器,传递给第 3 方日期选择器控件等)。据我所知,这里最小的公分母是 Date() 构造函数 - 如果浏览器的 JavaScript Date() 构造函数能够正确解释日期,那么其他一切都会正常工作。

因此,我的第一个想法是预处理这些仅限日期的字段,以将它们转换为 Date() 构造函数可以正确解释的格式。事实证明,找到这样的格式并非易事(请参阅我的相关问题:JavaScript date-only format guaranteed to be interpreted as local time in modern browsers

我的另一个想法是在客户端对 API 响应进行后处理(本质上,使用例如 moment.js 手动解析从 API 返回的所有字符串日期),但我想避免客户端 -梳理一个巨大的对象图并查找所有日期的侧面性能影响。

我猜这不是一个新的或特别独特的问题。还有其他我忽略的解决方案吗?如何在保持日期时区不可知的同时将仅日期字段从服务器传送到浏览器客户端?

【问题讨论】:

    标签: javascript date datetime cross-browser timezone


    【解决方案1】:

    在 JSON 中,最好的建议是坚持ISO8601 标准。对于没有时间的日期,那将是YYYY-MM-DD,例如:

    {
        "fooDate" : "2015-12-15"
    }
    

    造成这种情况的原因有很多,但一般来说,您应该以符​​合标准的格式通过网络发送数据,以便明确意图。一些解析器(无论是 JavaScript、浏览器还是其他)可能会错误地解释它,这是在那个环境中需要调整的,不是在序列化中

    因此,如果您在浏览器中收到此消息,您可以用斜杠替换连字符(根据 my answer to your other questionshown here also),或者使用 moment.js 之类的库进行解析,或者将字符串拆分为连字符并从部分​​构建日期(如果您要发送到 Date 构造函数,请小心从月份中减去 1)。

    需要考虑的另一点是,您的后端平台默认情况下可能不使用仅日期形式。例如,如果您在 .NET 中使用 DateTime 存储仅日期值,则将其视为午夜日期。因此,序列化可能最终包括时间,这是您在场景中不想要的。对于 .NET 开发人员,请使用来自 NodaTime 的 LocalDate,或等待 System.Date from CoreFXLab 进入生产就绪状态。

    其他平台可能也有类似的问题,但关键是,如果时间在您的数据中没有意义,则不应发送它。当您实际上是指"2015-12-15" 时,请不要发送"2015-12-15T00:00:00"。它们是两个不同的概念。

    【讨论】:

      【解决方案2】:

      我们有一个类似的应用程序,其中我们有一个称为“检查日期”的东西,它应该是一个没有时间的日期。我们的应用程序跨多个国家和时区运行,我们希望向所有用户显示相同的日期。

      当使用没有时间的日期时,大多数浏览器和服务器系统将假定时间为 00:00:00。在服务器上,我们的应用程序始终以 UTC 存储时间,用户总是在浏览器中看到本地时间。

      我们遇到的问题是,一些用户会将前一个日期视为检查日期,就像他们在西半球一样。

      想一想 - 一个简单的日期,比如 2015 年 12 月 18 日,实际上是不完整的信息,直到您同时说明该日期的位置。它现在在日本排在第 18 位,但在美国仍然排在第 17 位。

      然后我们意识到我们可以通过将日期转换为字符串(就在服务器上)并将其显示给用户来简单地忽略时区。但是,当我告诉他18日(在日本)发生检查时,这对美国用户意味着什么,这对他来说将是未来?据他所知,检查发生在17号。

      字符串解决方案对我们不起作用。我们选择了下一个最佳选项:根据执行日期的时区为日期分配 12:00 的时间。这给了我们最好的近似值,每个人都很高兴。靠近检查发生的时区的用户看到了正确的日期,而对面的用户也看到了正确的日期(根据他们)。 :)

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2019-03-22
        • 2016-12-29
        • 2015-09-15
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2016-07-30
        相关资源
        最近更新 更多