Re: [Json] Limitations on number size?

Tatu Saloranta <> Thu, 11 July 2013 04:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AF4D221F92BB for <>; Wed, 10 Jul 2013 21:10:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 01qapWrsW3ol for <>; Wed, 10 Jul 2013 21:10:09 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22c]) by (Postfix) with ESMTP id 3F59921F9263 for <>; Wed, 10 Jul 2013 21:10:07 -0700 (PDT)
Received: by with SMTP id q56so6617373wes.3 for <>; Wed, 10 Jul 2013 21:10:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=1RO9W9STxQDBEn2JmmiZt3hu0o9YXlDoYfZiKBra2FU=; b=uiB/gHKUDrsr1KUhkJyT4Z6k3bDC1luVZ28wM8TuqS+/ayit2m9oxT92/bTCBLJ1/N XAJQBxQYLZNW3jnaulp5QovUJWYmepX6jO9ygIV8evgyQFCTkPG/CYT/dUr60B9R7oR/ lvSiHHtUd5ZgJu35NN54o7QpKv5fxpt9la/yznw0nE2rRRPHvGg+OxHOcJdWhytNQCT+ YpZdT+j3IQU7Hkv4FMh70tvcLs4rfHqf1NBKEXWPFjov8QvyibL95DxiZu6ejvcigl3n REzaqlaQe0m0aN+EyjlwD5XqXZDGq+9ISddeEtFldXFiNl/yMBfaM2GCF8wUy0ww1Ql7 AiGw==
MIME-Version: 1.0
X-Received: by with SMTP id lm6mr36671963wic.50.1373515807246; Wed, 10 Jul 2013 21:10:07 -0700 (PDT)
Received: by with HTTP; Wed, 10 Jul 2013 21:10:07 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Wed, 10 Jul 2013 21:10:07 -0700
Message-ID: <>
From: Tatu Saloranta <>
To: Jacob Davies <>
Content-Type: multipart/alternative; boundary=001a11c265bec8d04604e1349100
Cc: "Peter F. Patel-Schneider" <>, Nico Williams <>, Bjoern Hoehrmann <>, John Cowan <>, "" <>
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: Thu, 11 Jul 2013 04:10:09 -0000

On Wed, Jul 10, 2013 at 2:32 PM, Jacob Davies <> wrote:

> On Tue, Jul 9, 2013 at 7:42 PM, John Cowan <> wrote:
> > Apparently, there are already practical problems with interchanging
> > 64-bit longs: google for [json large numbers bugs] for lots of reports.
> The canonical one was Twitter IDs, where they had to introduce a
> (string) field in their JSON APIs called "id_str" which is not
> guaranteed to be equal to the obsolete-but-included (number) field
> "id".
> > While there are apparently int32-only systems out there, it's clearly
> > understood that they are unusually restricted: such is not the case
> > for JavaScript-hosted implementations.
> Yes, this is why I think the specification itself should note that for
> interoperability with Javascript, the Javascript size limitations must
> be respected, even if the specification does not require that in
> itself. The number of JSON-to-Javascript implementations or uses must
> surely outnumber all other uses of JSON by several orders of magnitude
> so I'd argue that as far as "running code" goes the limitation on

Any data to back that up? I would not assume this -- JSON is being used a
lot for service-to-service integration, as well as by native mobile clients.
Javascript as client is certainly important, but I would not assume any
particular majority (even simple one), and certainly not an order of

My experience wrt problem reports differs from that of John's, in that
while feature requests have been filed to allow limitation or truncation,
these have not been highly voted or actively followed. User community also
has not brought this up as a significant issue either.
I suspect this is because it is relatively easy to work around the problem
if and when it occurs. Developers are surprisingly resourceful in solving

practical, interoperable number size is quite real and surprising to
> people trying to send data to Javascript from non-JS environments
> where larger numbers are available. (I went so far in the Java
> libraries I wrote as to encode/decode longs & Big* as strings.)

Mentioning limitations is reasonable, and Javascript can be used as a
common example. There is nothing wrong in outlining challenges, best
practices. But I don't like fearmongering.

Javascript's limited support for numbers is not a JSON-specific problem --
same goes for all data formats as well; for example, XML. This is why some
concerns wrt JSON seem overblown to me.

-+ Tatu +-