Re: [Json] Limitations on number size?

"Peter F. Patel-Schneider" <> Tue, 09 July 2013 13:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4132411E812A for <>; Tue, 9 Jul 2013 06:26:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XfpGMLY3yQeS for <>; Tue, 9 Jul 2013 06:26:49 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c02::22a]) by (Postfix) with ESMTP id 482D811E8128 for <>; Tue, 9 Jul 2013 06:26:49 -0700 (PDT)
Received: by with SMTP id j6so8034401oag.29 for <>; Tue, 09 Jul 2013 06:26:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=uMQNhwPrnFLdDS/3cpbhThrW4KbRSzerSDk238Q2WWE=; b=VDbU+Q+tfUT51qO3xtdnci/h3rCv1d+rAOR/itW80TkrWeyObpqnykWvVwi4d05dLt tjvfg3Q1ecPfVBt13nR4cjVVV3DixPyN5Iuzu4A5k6aZCtxjsrTjKM2UXnssa+NZSRxx ooRR5OpNFaxdkJkT9Atqgzz7uXk002V2aJRH1VgsTp9ocmEQh5uknw4+WnR79JuG1hxs WiPU/V+3pyz0r6z1t4eqsbEi+/vlrZR2AUGubqD2K1jCW8UWlF2/zfqHWo5/ZtnF7Alp m+en/RQqOeFVbIMR+qq1jNvNVOn8KgROMQ3hPOSKIpjD0n8CxQlbVwHLGfxXYRWl16LF JzdA==
X-Received: by with SMTP id ii1mr23779599obc.93.1373376407778; Tue, 09 Jul 2013 06:26:47 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id kz3sm38054410obb.6.2013. for <> (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Jul 2013 06:26:47 -0700 (PDT)
Message-ID: <>
Date: Tue, 09 Jul 2013 06:26:45 -0700
From: "Peter F. Patel-Schneider" <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Json] Limitations on number size?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "JavaScript Object Notation \(JSON\) WG mailing list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 09 Jul 2013 14:07:06 -0000

[I'm picking up this discussion rather late, but the issue has come up in 
JSON-LD, so I'm putting my oar in.]

My informed understanding of JSON, from reading all the relevant documents, 
was (and again is) also that JSON numbers are ECMAScript numbers are IEEE 
floating point doubles (minus some odd bits).  I was astonished to find out 
that some people disagree, apparently to the point that they believe that 0 is 
different from .0

Not being clear on the primitive data types in JSON is a very bad thing, in my 

Peter F. Patel-Schneider

From: Jacob Davies <jacob at>
To: "json at" <json at>
Date: Wed, 5 Jun 2013 10:51:58 -0700

On Tue, Jun 4, 2013 at 9:05 PM, Nico Williams <nico at> wrote:

     It might be nice to be able to specify some ranges that MUST be
     supported by decoders, but in practice I think we can't (and probably
     shouldn't try to) even do that.

My past reading of the number section and the many references to _javascript_ 
in the spec led me to believe that the number type was _javascript_'s number 
type, and that compliance required you to accept & emit numbers only in that 
range (i.e. IEEE 754 64-bit numbers minus NaN and infinities).

Implementation limits on the length of strings or size of arrays or objects 
were not specified either, but those are large enough in most languages that 
you're unlikely to run into them unexpectedly; if you are thinking of sending 
a terabyte of text in string or an object with a trillion keys it has probably 
occurred to you that some special interoperability concerns will apply. But 
just sending large 64-bit integers as numbers in a JSON string will cause you 
interoperability problems with _javascript_ and a lot of other JSON parsers, 
and my experience & some quick searches indicate this has been a common bug 
(or misunderstanding, perhaps) in implementations.

I wouldn't say a size restriction should be specified either. But I think it 
might be worth noting this particular interoperability concern in the 
specification rather than just as a best practice.