Recommend using RFC 3339 formats for dates in strings

[icefoxen]

All you need is "It is recommended (but not required) that dates and times be represented as strings formatted per ISO 8601".

Then anyone who needs to build a library to handle dates and times can look up the standard and say "Oh, that's reasonable, I'll do that".

This is a known and persistent problem with existing solutions, and not using an existing solution seems unnecessarily obtuse.

[jordanbtucker]

I like this idea. However, instead of ISO 8601, I would say that dates should be converted to UTC and represented as strings in Internet Date/Time Format as defined by RFC 3339.

ISO 8601 is not a free standard, and it supports a very broad range of date and time formats. RFC 3339 defines an ISO 8601 profile that provides a high level of interoperability.

[jordanbtucker]

I added the following section to a new v1.1.0 branch.

Dates and Times

It is recommended that JSON5 generators convert date and time values to Coordinated Universal Time (UTC) and represent them as strings in internet format as defined by RFC 3339 in the interest of interoperability.

Example 1 (Informative)

{
    billenium: '2001-09-09T01:46:40Z',
}

Alternatively, JSON5 generators may represent dates and times as Unix time, which is the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, minus the number of leap seconds that have taken place since then.

Example 2 (Informative)

{
    json5Birthday: 1338150759534,
}

If a JSON5 parser expects a value to be a date or time, it may attempt to convert the value from one of the earlier defined formats to a date or time.

[tracker1]

Most JSON encoders/stringify respect objects with a .toJSON() method and use that for encoding... Date has such a method, and it encodes to ISO-8601 format. It may not be part of the JSON standard, but it has effectively become part of ECMA/W3C standard.

At this point, the best bet would be to support automatic hydration of full ISO strings that match a .toJSON() output to dates. Extended formats should be possible, but wouldn't want to create a specification for this that effectively breaks the internet, so to speak.

I would propose that if new Date functionality is really desired, particularly in encoding/decoding with JSON5, then a Date2 object/class be created in order to facilitate that functionality. Cleaning up timezone interactions and conversions should also probably be a priority. I'd suggest looking to moment and moment-tz for inspiration. There have been discussions with tc39 on this subject.

[jordanbtucker]

@tracker1 I'm hesitant to have parsers automatically convert date-like strings to dates. Strings would no longer be just strings, but they'd also be maybe-dates. And if the platform doesn't have support for fractions of seconds, then the string '2018-03-16T22:36:13.713Z' would lose information if forced into a less precise date construct.

The nature of strings is that they can be very precise if need be. For example, the number 1e-1000 may get rounded to zero, but the string '1e-1000' can't lose precision.

Developers are welcome to write parsers that convert strings to dates, and in fact I've tried the idea myself, but I don't think it should be the standard.

[tracker1]

I'm fine with not doing anything with it... just didn't want to add something to the spec regarding dates, as date encoding already has a defacto implementation.

[icefoxen]

If you have a defacto implementation, other people are just going to implement it wrong. If you have a standard that people can test against, they know how to implement it right. This is what standards are for.

[dcleao]

The only safe solution, imo, is to extend the spec to have some form of tagged literals, as was proposed on the original discussion: json5/json5#3 (comment). Besides, this solution would allow supporting any custom types of literals.

Probably, the best bet would be to use the same syntax as the new ECMAScript tagged template literals: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals.

Note that supported tags and their evaluation functions would always need to be registered with the parser, thus allowing full control of supported types of literals and simultaneously ensuring the safety of the solution.

[bogdan]

My main problems with dates are inside API calls:
Client code has to know that specific fields in JSON structure returned by the API are dates and need to be parsed manually over and over again for each API call that returns dates. That is pretty common in all web apps.

I was thinking about allowing something like this in JSON:

{
  firstName: 'John',
  lastName: 'Smith',
  birthday: new Date('1986-08-04'),
  createdAt: new Date('2019-07-24T13:37:34.752Z'),
}

[tracker1]

If the spec is extended, I'd prefer bogdan's solution... though, would probably be somewhat better to remain compatible as a string.

// USE ASCII Characters for kind of what they are meant for.
const DLE = String.fromCharCode(16); // Data Link Escape
const SOH = String.fromCharCode(1); // start of heading
const STX = String.fromCharCode(2); // start ot text
const ETX = String.fromCharCode(3); // end of text
const EOT = String.fromCharCode(4); // end of transmission
const DLE = String.fromCharCode(16); // Data Link Escape

An encoded data record should start with:

   // Encoded record ...
   `${DLE}${SOH}TYPE${STX}DATA${ETX}${EOT}${DLE}`

If the string starts with DLE + SOH and ends with ETX + EOT + DLE then it can be checked for an encoding. Further split on STX into header and body parts.

In this case TYPE could be "DATE/RFC3339" and the DATA would be a properly encoded string.

In this way, we could use existing escape characters for encoded data, and if there's a supported decoder, it can be added and handle any encoded complex type, while still complying with original JSON.

---

For more complex data types, there's also...

const FS = String.fromCharCode(28); // file separator
const GS = String.fromCharCode(29); // group separator
const RS = String.fromCharCode(30); // record separator
const US = String.fromCharCode(31); // unit separator

https://gist.github.com/tracker1/84fd0c1a31b3d17b176495f37b3431ba

[jordanbtucker]

I don't think it's a good idea to start treating strings as maybe-dates, especially when it breaks backward compatibility.

On another note, I think putting non-printable characters in strings would make JSON5 less human readable than JSON.

[mindplay-dk]

In my opinion, platforms and languages have too many differences when it comes to date/time storage, time-zone conversions, parsing, formatting, precision, etc. - and also, these are often subject to change on various systems as they evolve over time, adding/removing time-zone, changing precision, etc.

I think that specifying anything about dates is probably unnecessary, as most systems already specify how they want dates/timestamps represented - and usually with good reason, as it has to match their back-end database or other systems, so it's most likely safer to stay away from this topic entirely.