“正确”的JSON日期格式

10 回答

• -4

  它可以解析我的解析服务器

  {
      "ContractID": "203-17-DC0101-00003-10011",
      "Supplier":"Sample Co., Ltd",
      "Value":12345.80,
      "Curency":"USD",
      "StartDate": {
                  "__type": "Date",
                  "iso": "2017-08-22T06:11:00.000Z"
              }
  }
  

  回复于 2024-04-26T04:20:18+08:00
• -3

  以下代码对我有用 . 此代码将以 DD-MM-YYYY 格式打印日期 .

  DateValue=DateValue.substring(6,8)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(0,4);
  

  否则，你也可以使用：

  DateValue=DateValue.substring(0,4)+"-"+DateValue.substring(4,6)+"-"+DateValue.substring(6,8);
  

  回复于 2024-04-26T04:20:18+08:00
• -12

  There is no right format ; JSON specification 没有指定交换日期的格式，这就是为什么有这么多不同的方法来做到这一点 .

  The best format is arguably a date represented in ISO 8601 format （see Wikipedia）;它是一种众所周知且广泛使用的格式，可以跨多种语言处理，非常适合互操作性 . 例如，如果您可以控制生成的json，则以json格式向其他系统提供数据，选择8601作为日期交换格式是一个不错的选择 .

  例如，如果您无法控制生成的json，那么您是来自几个不同现有系统的json的使用者，处理此问题的最佳方法是使用日期解析实用程序函数来处理预期的不同格式 .

  回复于 2024-04-26T04:20:18+08:00
• 0

  JSON对日期一无所知 . .NET所做的是非标准的黑客/扩展 .

  我会使用一种可以在JavaScript中轻松转换为 Date 对象的格式，即可以传递给new Date(...)的格式 . 最简单且可能最便携的格式是自1970年以来包含毫秒的时间戳 .

  回复于 2024-04-26T04:20:18+08:00
• 21

  JSON本身 does not 指定日期应该如何表示，但JavaScript确实如此 .

  你应该使用Date的toJSON方法发出的格式：

  2012-04-23T18:25:43.511Z

  原因如下：

  • 这是人类可读但也简洁

  • 它正确排序

  • 它包括小数秒，可以帮助重建年表

  • 符合ISO 8601

  • ISO 8601已在国际上 Build 了十多年

  • ISO 8601由W3C，RFC3339和XKCD认可

  That being said ，每个写过的日期库都能理解"milliseconds since 1970" . 所以为了便于携带，ThiefMaster是对的 .

  回复于 2024-04-26T04:20:18+08:00
• 1471

  在Sharepoint 2013中，使用JSON获取数据没有格式将日期转换为仅日期格式，因为在该日期应该是ISO格式

  yourDate.substring(0,10)
  

  这可能对你有所帮助

  回复于 2024-04-26T04:20:18+08:00
• 108

  只有一个正确答案，大多数系统都错了 . 自纪元以来的毫秒数，也就是64位整数 . 时区是UI关注点，在应用层或数据库层中没有业务 . 为什么你的数据库关心什么时区是什么，当你知道它将它存储为64位整数然后进行转换计算 .

  删除无关的位，只需将日期视为数字直至UI . 您可以使用简单的算术运算符来执行查询和逻辑 .

  回复于 2024-04-26T04:20:18+08:00
• 33

  我认为这实际上取决于用例 . 在许多情况下，使用适当的对象模型（而不是将日期呈现为字符串）可能更有益，如下所示：

  {
  "person" :
        {
   "name" : {
     "first": "Tom",
     "middle": "M",
    ...
  }
   "dob" :  {
           "year": 2012,
           "month": 4,
           "day": 23,
           "hour": 18,
           "minute": 25,
           "second": 43,
           "timeZone": "America/New_York"
      }   
     }
  }
  

  不可否认，这比RFC 3339更冗长，但是：

  • 它也是人类可读的

  • 它实现了一个正确的对象模型（就像在OOP中一样，只要JSON允许它）

  • 它支持时区（不仅仅是给定日期和时间的UTC偏移）

  • 它可以支持更小的单位，如毫秒，纳秒，......或简单的小数秒

  • 它不需要单独的解析步骤（解析日期时间字符串），JSON解析器将为您完成所有事情

  • 使用任何语言的任何日期时间框架或实现轻松创建

  • 可以很容易地扩展到支持其他日历尺度（希伯来语，中文，伊斯兰......）和时代（AD，BC，...）

  • it 's year 10000 safe ;-) (RFC 3339 isn' t）

  • 支持全天日期和浮动时间（Javascript的 Date.toJSON() 不支持）

  我不认为正确排序（如RFC 3339的funroll所述）是将日期序列化为JSON时真正需要的功能 . 此外，对于具有相同时区偏移的日期时间也是如此 .

  回复于 2024-04-26T04:20:18+08:00
• 9

  仅供参考我见过这种格式：

  Date.UTC(2017,2,22)
  

  它适用于 $.getJSON() 函数支持的 JSONP . 我不确定我会推荐这种方法......只是把它扔出去作为一种可能性，因为人们这样做 .

  FWIW: 永远不要使用通信协议中的纪元以来的秒数，也不要使用自纪元以来的毫秒数，因为随着闰秒的随机实施，这些都充满了危险（你不知道发送方和接收方是否都正确地实现了UTC闰秒） .

  一种宠物讨厌，但很多人认为UTC只是GMT的新名称 - 错！如果您的系统没有实现闰秒，那么您使用GMT（尽管不正确，通常称为UTC） . 如果您完全实现闰秒，那么您确实使用的是UTC . 未来的闰秒无法知晓;它们在必要时由IERS发布，需要不断更新 . 如果您正在运行尝试的系统实现闰秒，但包含和过时的参考表（比你想象的更常见）然后你既没有GMT，也没有UTC，你有一个假冒的UTC系统 .

  这些日期计数器仅在以细分格式（y，m，d等）表示时才兼容 . 它们永远不会以时代格式兼容 . 记在脑子里 .

  回复于 2024-04-26T04:20:18+08:00
• -3

  来自RFC 7493 (The I-JSON Message Format )：

  I-JSON代表Internet JSON或Interoperable JSON，具体取决于您的要求 .

  协议通常包含旨在包含时间戳或持续时间的数据项 . 建议所有这些数据项表示为ISO 8601格式的字符串值，如RFC 3339中所规定，附加限制是使用大写字母而不是小写字母，包含时区不是默认值，以及可选的尾随秒数即使它们的值为“00”也要包括在内 . 还建议所有包含持续时间的数据项符合RFC 3339附录A中的“持续时间”生成，并具有相同的附加限制 .

  回复于 2024-04-26T04:20:18+08:00