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 1335205592410-0500            NET DataContractJsonSerializer  2012-04-23T18 25 43 511Z               JavaScript built-in JSON object  2012-04-21T18 25 43-05 00              ISO 8601   Which one is the right one  Or best  Is there any sort of standard on this

User · Answer

When in doubt simply go to the javascript web console of a modern browser by pressing F12 (Ctrl+Shift+K in Firefox) and write the following:

new Date().toISOString()

Will output:

"2019-07-04T13:33:03.969Z"

Ta-da!!

User · Answer

quot 2014-01-01T23 28 56 782Z quot  The date is represented in a standard and sortable format that represents a UTC time  indicated by the Z   ISO 8601 also supports time zones by replacing the Z with   or     value for the timezone offset   quot 2014-02-01T09 28 56 321-10 00 quot  There are other variations of the timezone encoding in the ISO 8601 spec  but the    10 00 format is the only TZ format that current JSON parsers support  In general it   s best to use the UTC based format  Z  unless you have a specific need for figuring out the time zone in which the date was produced  possible only in server side generation   NB      var date   new Date        console log date      Wed Jan 01 2014 13 28 56 GMT-      1000  Hawaiian Standard Time                var json   JSON stringify date       console log json        quot 2014-01-01T23 28 56 782Z quot   To tell you that s the preferred way even though JavaScript doesn t have a standard format for it    JSON encoded date var json    quot   quot 2014-01-01T23 28 56 782Z  quot  quot    var dateStr   JSON parse json     console log dateStr      2014-01-01T23 28 56 782Z

User · Answer

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

User · Answer

I believe that the best format for universal interoperability is not the ISO-8601 string  but rather the format used by EJSON      myDateField       date     lt ms-since-epoch gt       As described here  https   docs meteor com api ejson html  Benefits   Parsing performance  If you store dates as ISO-8601 strings  this is great if you are expecting a date value under that particular field  but if you have a system which must determine value types without context  you re parsing every string for a date format  No Need for Date Validation  You need not worry about validation and verification of the date  Even if a string matches ISO-8601 format  it may not be a real date  this can never happen with an EJSON date  Unambiguous Type Declaration  as far as generic data systems go  if you wanted to store an ISO string as a string in one case  and a real system date in another  generic systems adopting the ISO-8601 string format will not allow this  mechanically  without escape tricks or similar awful solutions     Conclusion  I understand that a human-readable format  ISO-8601 string  is helpful and more convenient for 80  of use cases  and indeed no-one should ever be told not to store their dates as ISO-8601 strings if that s what their applications understand  but for a universally accepted transport format which should guarantee certain values to for sure be dates  how can we allow for ambiguity and need for so much validation

User · Answer

There is no right format  The JSON specification does not specify a format for exchanging dates which is why there are so many different ways to do it   The best format is arguably a date represented in ISO 8601 format  see Wikipedia   it is a well known and widely used format and can be handled across many different languages  making it very well suited for interoperability  If you have control over the generated json  for example  you provide data to other systems in json format  choosing 8601 as the date interchange format is a good choice   If you do not have control over the generated json  for example  you are the consumer of json from several different existing systems  the best way of handling this is to have a date parsing utility function to handle the different formats expected

User · Answer

In Sharepoint 2013  getting data in JSON there is no format to convert date into date only format  because in that date should be in ISO format  yourDate substring 0 10    This may be helpful for  you

User · Answer

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

User · Answer

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

User · Answer

JSON itself has no date format  it does not care how anyone stores dates  However  since this question is tagged with javascript  I assume you want to know how to store javascript dates in JSON  You can just pass in a date to the JSON stringify method  and it will use Date prototype toJSON by default  which in turns uses Date prototype toISOString  MDN on Date toJSON    const json   JSON stringify new Date     const parsed   JSON parse json     2015-10-26T07 46 36 611Z const date   new Date parsed      Back to date object   I also found it useful to use the reviver parameter of JSON parse  MDN on JSON parse  to automatically convert ISO strings back to javascript dates whenever I read JSON strings   const isoDatePattern   new RegExp   d 4 - 01  d- 0-3  dT 0-2  d  0-5  d  0-5  d   d    -  0-2  d  0-5  d Z      const obj      a   foo    b  new Date 1500000000000     Fri Jul 14 2017  etc      const json   JSON stringify obj       Convert back  use reviver function  const parsed   JSON parse json   key  value    gt        if  typeof value      string   amp  amp   value match isoDatePattern            return new Date value      isostring  so cast to js date           return value     leave any other value as-is     console log parsed b         Fri Jul 14 2017  etc

User · Answer

The following code has worked for me  This code will print date in DD-MM-YYYY format   DateValue DateValue substring 6 8   -  DateValue substring 4 6   -  DateValue substring 0 4     else  you can also use   DateValue DateValue substring 0 4   -  DateValue substring 4 6   -  DateValue substring 6 8

User · Answer

Just for reference I ve seen this format used   Date UTC 2017 2 22    It works with JSONP which is supported by the   getJSON   function  Not sure I would go so far as to recommend this approach    just throwing it out there as a possibility because people are doing it this way   FWIW  Never use seconds since epoch in a communication protocol  nor milliseconds since epoch  because these are fraught with danger thanks to the randomized implementation of leap seconds  you have no idea whether sender and receiver both properly implement UTC leap seconds    Kind of a pet hate  but many people believe that UTC is just the new name for GMT -- wrong  If your system does not implement leap seconds then you are using GMT  often called UTC despite being incorrect   If you do fully implement leap seconds you really are using UTC  Future leap seconds cannot be known  they get published by the IERS as necessary and require constant updates  If you are running a system that attempts to implement leap seconds but contains and out-of-date reference table  more common than you might think  then you have neither GMT  nor UTC  you have a wonky system pretending to be UTC   These date counters are only compatible when expressed in a broken down format  y  m  d  etc   They are NEVER compatible in an epoch format  Keep that in mind

User · Answer

If you are using Kotlin then this will solve your problem   MS Json format   val dataString     Date 1586583441106    val date   Date Long parseLong dataString substring 6  dataString length - 2

User · Answer

JSON itself does not specify how dates should be represented  but JavaScript does   You should use the format emitted by Date s toJSON method   2012-04-23T18 25 43 511Z  Here s why    It s human readable but also succinct It sorts correctly It includes fractional seconds  which can help re-establish chronology It conforms to ISO 8601 ISO 8601 has been well-established internationally for more than a decade ISO 8601 is endorsed by W3C  RFC3339  and XKCD   That being said  every date library ever written can understand  milliseconds since 1970   So for easy portability  ThiefMaster is right

User · Answer

JSON does not know anything about dates  What  NET does is a non-standard hack extension   I would use a format that can be easily converted to a Date object in JavaScript  i e  one that can be passed to new Date       The easiest and probably most portable format is the timestamp containing milliseconds since 1970

User · Answer

From RFC 7493  The I-JSON Message Format     I-JSON stands for either Internet JSON or Interoperable JSON  depending on who you ask      Protocols often contain data items that are designed to contain   timestamps or time durations   It is RECOMMENDED that all such data   items be expressed as string values in ISO 8601 format  as specified   in RFC 3339  with the additional restrictions that uppercase rather   than lowercase letters be used  that the timezone be included not   defaulted  and that optional trailing seconds be included even when   their value is  00    It is also RECOMMENDED that all data items   containing time durations conform to the  duration  production in   Appendix A of RFC 3339  with the same additional restrictions

User · Answer

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

[javascript] What is the "right" JSON date format?

Examples related to javascript

Examples related to json