Json compare format code#
Json compare format iso#

In an application means you’d have to manually replace dates every time you use them or do any sort of date math. This works nicely for single dates, but unfortunately it’s a bit of a pain if you get back complex objects that contain dates: An object with a few date fields or an array containing objects with date fields requires that you to fix up each of the values at the point of use.

Note that the string that is passed to new Date() has to be a plain string, not a JSON string so make sure if there are quote wrappers around a JSON string to remove the quotes.

Json compare format iso#

The following turns the ISO date back into a ‘real’ date: // JSON encoded date The date constructor accepts a wide variety of inputs to construct a date, ISO 8601 amongst them. The good news – and maybe not very widely known news at that – is that ISO dates can be easily converted into JavaScript dates by use of the flexible JavaScript Date constructor. This is because the JSON created is in fact a string and JSON.parse() doesn’t know anything other than that the encoded date value is a string, so that’s what you get back. No quotes this time – it’s no longer a JSON string, but a string nevertheless. You’ll find that you get back… drum roll… a string in dateStr: If you now want to deserialize that JSON date back into a date you’ll find that JSON.parse() doesn’t do the job. This produces a JSON encoded string value: To encode a date with JSON you can just use the standard JSON serializer’s stringify() method: var date = new Date() Ĭonsole.log(date) // Wed 13:28:56 GMT-1000 (Hawaiian Standard Time) How Date Parsing Works with JSON Serializers There have been other date formats in the past – namely Microsoft’s MS AJAX style date (/Date(454123112)/) which Microsoft used in their original AJAX and REST products (Microsoft AJAX and WCF REST specifically), but which thankfully have disappeared in new frameworks (ASP.NET Web API, Nancy, ServiceStack etc.) in favor of ISO style dates that are now ubiquitous. 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). 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. ISO 8601 also supports time zones by replacing the Z with + or – value for the timezone offset: The date is represented in a standard and sortable format that represents a UTC time (indicated by the Z). You can serialize to this format, but there’s no direct deserialization back to a date from it.

Dates are encoded as ISO 8601 strings and then treated just like a regular string when the JSON is serialized and deserialized. There’s no ‘official’ standard for what the date format should look like, although it’s been more or less agreed upon that the JSON Date encoding format should be ISO 8601 as that’s what all the major browser native JSON parsers use. So in order to represent dates in JavaScript, JSON uses a specific string format – ISO 8601 – to encode dates as string. Which seems like a rather major omission given that dates are pretty important in computing and business environments. You can represent strings, numbers, Booleans and even objects, arrays and RegEx expressions with language specific literals, but there’s no equivalent literal representation for dates. The problem with dates in JSON – and really JavaScript in general – is that JavaScript doesn’t have a date literal. JSON Dates are not dates – they are Strings I find this functionality indispensable and use as part of my own libraries in just about every client-side application that uses AJAX.

Json compare format code#

The code and small support library discussed in this post is up on GitHub in my json.date-extensions library, so you can download and play around with this yourself. In this post I’ll discuss the problem and a few workarounds as well as small JSON extension library that you can use to globally parse JSON with proper date conversion with minimal fuss. I’ve talked about this topic a few times in the past, but I thought I’d revisit because it’s one that comes up quite frequently, and because in the interceding years I’ve started using a more flexible solution than what I previously discussed. Or more precisely – it serializes dates just fine, it just doesn’t deserialize them. But yet there’s at least one very annoying problem with JSON: It doesn’t serialize dates. It’s used for transport serialization for just about anything REST related these days, for configuration management, for storage and data representation in many database formats (NoSql). For Web based applications one could say it’s become the serialization format. JSON has become a rather prevalent serialization format in recent years.