Re: [Json] Limitations on number size?

Jacob Davies <> Wed, 10 July 2013 21:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2274121F9D80 for <>; Wed, 10 Jul 2013 14:33:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ySeKhRZFrO7A for <>; Wed, 10 Jul 2013 14:33:08 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c02::234]) by (Postfix) with ESMTP id 9C05211E8123 for <>; Wed, 10 Jul 2013 14:33:07 -0700 (PDT)
Received: by with SMTP id i11so4017308qej.25 for <>; Wed, 10 Jul 2013 14:33:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=5jO3ePxbljNRf+n8FUCUqVpN8/wo1OhHmBgoApnwmsg=; b=MW2M8hLHiPJimri9tgfKFXo/QwCt/sp/KLYjujwcdHNERCuhMRo2YmkaAa6bq3Y4Mb paIefy+XoXwjeATNILtv22kjlCfMtSRB3GXvVY6/YPl7GWYMzAyl8/DfSDA4jeD5GbYe ScvnKF84FFsBwy1k5MKG3lK32IEfLnPrQIipGlly2MbHRugTbbmW6HznLpOZd+kFHO4O jNFKbE1lKVplUymggFNm7Y/9P7IOAILW1CuDjnHqNsb+mRZkxNF+GUQimc3QFHT+nKpN gh7YBGBO8aJO8eiUUxWu/YZiph4wg0f1GUP5peehVi8HWXVmgjYojiYTlK64mkvrg3cx vvDQ==
X-Received: by with SMTP id gb3mr27293703qeb.77.1373491986745; Wed, 10 Jul 2013 14:33:06 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 10 Jul 2013 14:32:42 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Jacob Davies <>
Date: Wed, 10 Jul 2013 14:32:42 -0700
X-Google-Sender-Auth: ImQG6MebLhECd7lGPZ7oKKdUsDA
Message-ID: <>
To: John Cowan <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "Peter F. Patel-Schneider" <>, Nico Williams <>, Bjoern Hoehrmann <>, Tatu Saloranta <>, "" <>
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: Wed, 10 Jul 2013 21:33:09 -0000

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

> 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
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.)