What is the “right” JSON date format?

Question

I\'ve seen so many different standards for the JSON date format:

\"\\\"\\\\/Date(1335205592410)\\\\/\\\"\"         .NET JavaScriptSerializer
\"\\\"\\\\/Date(         


        

Answer 1

There is only one correct answer to this and most systems get it wrong. Number of milliseconds since epoch, aka a 64 bit integer. Time Zone is a UI concern and has no business in the app layer or db layer. Why does your db care what time zone something is, when you know it's going to store it as a 64 bit integer then do the transformation calculations.

Strip out the extraneous bits and just treat dates as numbers up to the UI. You can use simple arithmetic operators to do queries and logic.

Answer 2

The prefered way is using 2018-04-23T18:25:43.511Z...

The picture below shows why this is the prefered way:

So as you see Date has a native Method toJSON, which return in this format and can be easily converted to Date again...

Answer 3

I think that really depends on the use case. In many cases it might be more beneficial to use a proper object model (instead of rendering the date to a string), like so:

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

Admittedly this is more verbose than RFC 3339 but:

• it's human readable as well
• it implements a proper object model (as in OOP, as far as JSON permits it)
• it supports time zones (not just the UTC offset at the given date and time)
• it can support smaller units like milliseconds, nanoseconds, ... or simply fractional seconds
• it doesn't require a separate parsing step (to parse the date-time string), the JSON parser will do everything for you
• easy creation with any date-time framework or implementation in any language
• can easily be extended to support other calendar scales (Hebrew, Chinese, Islamic ...) and eras (AD, BC, ...)
• it's year 10000 safe ;-) (RFC 3339 isn't)
• supports all-day dates and floating times (Javascript's Date.toJSON() doesn't)

I don't think that correct sorting (as noted by funroll for RFC 3339) is a feature that's really needed when serializing a date to JSON. Also that's only true for date-times having the same time zone offset.

Answer 4

it is work for me with parse Server

{
    "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"
            }
}