由于 JSON 只是 JavaScript 文字的子集，因此可以使用将源JSON 字符串视为 JavaScript 源代码的 eval(expr) 函数，来分析内存中表示形式,。eval 函数接受输入有效 JavaScript 代码的字符串，并计算表达式结果。

因此，将 JSON 用作数据格式的大多数应用程序通常会使用字符串或数字来表示日期和时间值。如果使用的是字符串，您通常希望它是 ISO 8601 格式。如果使用的是数字，该值通常表示从JSON 字符串、以通用协调时间 (UTC) 表示的毫秒数，其中 epoch 定义为 1970 年 1 月 1 日午夜 (UTC)。同样，这仅仅是个惯例，而不是 JSON 标准的一部分。

如果您要与其他应用程序交换数据，则需要检查其文档，查看它对 JSON 文字内的日期和时间值是如何进行编码的。例如，Microsoft 的 ASP.NET AJAX 使用的就不是上述任一种惯例。它代之以将 .NET DateTime 值编码为 JSON 字符串，字符串内容是 \/Date(ticks)\/，其中 ticks 表示从 epoch (UTC) 开始的毫秒数。

ASP.NEXT 中的 AJAX JSON 序列化程序将 DateTime 实例编码为 JSON 字符串。在预发布周期中，ASP.NET AJAX 使用格式“@ticks@”，其中 ticks 表示从通用协调时间 (UTC) 1970 年 1 月 1 日起经过的毫秒数。以 UTC 表示的日期和时间。#t#

（如 1989 年 11 月 29 日 4:55:30 AM）会编码为“@62831853071@”。虽然简单易懂，但此格式无法区分序列化的日期和时间值与看起来像序列化日期但又不需要进行反序列化的值。因此，ASP.NET AJAX 团队对最终版本进行了更改，通过采用“\/Date(ticks)\/”格式解决了这一问题。

JSON 和 XML 均能够以基于文本、便于读者阅读的数据交换格式来表示本机内存中对象。此外，两种数据交换格式是同构的，只要文本是一种格式，即可得出另外一种格式的等效文本。例如，调用 可公开访问的 Yahoo! web 服务之一时，您可以通过 querystring 参数指明响应需要设置为 XML 还是 JSON 格式。

因此，决定数据交换格式时，不是简单的选此或彼作为银弹的问题，而是要看哪种格式具有成为特定应用程序的***选择的“特征”。

例如，JSON 字符串 起源于标记文档文本，而且有继续在该领域发扬光大的趋势（XHTML 就是很好的证明）。而 JSON 则起源于编程语言类型和结构，因此提供了更加自然和便于使用的交换结构化数据映射。除了这两个起点之外，下表可帮助您了解和比较 XML 与 JSON 的重要特征。