Re: [Json] Limitations on number size?

Stephan Beal <> Wed, 10 July 2013 09:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F8EA21F9F75 for <>; Wed, 10 Jul 2013 02:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W90qFJi69sh5 for <>; Wed, 10 Jul 2013 02:48:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c01::22f]) by (Postfix) with ESMTP id 860C321F9F6D for <>; Wed, 10 Jul 2013 02:48:00 -0700 (PDT)
Received: by with SMTP id rr13so6533529pbb.34 for <>; Wed, 10 Jul 2013 02:47:59 -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 :content-type; bh=mJ+A/NsJ/17UQzk18zE6Wh0XQaxUi5G4p6zKp2LuK3Q=; b=GhApHlOwt99AJgMb6hZPC0J59W+gv6XFC8E/xuN8EkEVXGnq+cwY7/ddsXiAv4bLOT MDGwdQZ2YzGYtBGLhE2HX24CydixkLEVH1/R5AdbENyQr13M72gNAG6tS4aEKZcOQmkC EVXsoLNyZuqYb3gpz4QdoeRcPUnta7vHS1EiDlSY8YQ0F18m/qVZrxP/LW2actHn0SLg tuQuEifX5RIR7yTfD776/Tr6yU5PofRLlIK6aIE0Wbs9Q8iUahlnz+Dv8s2aDeYUB9qW J024oJA+iXs9oimZAwKRf0UvRuoGzPnebrLjHbZlT2FYf5owJjZg8TSaTNZD4EF9i7wM IFsA==
MIME-Version: 1.0
X-Received: by with SMTP id ll10mr31786445pab.126.1373449679540; Wed, 10 Jul 2013 02:47:59 -0700 (PDT)
Received: by with HTTP; Wed, 10 Jul 2013 02:47:59 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
Date: Wed, 10 Jul 2013 11:47:59 +0200
Message-ID: <>
From: Stephan Beal <>
To: "" <>
Content-Type: multipart/alternative; boundary=047d7b41bb0e441f2e04e1252cde
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 09:48:01 -0000

On Wed, Jul 10, 2013 at 1:44 AM, Peter F. Patel-Schneider <> wrote:

> That's a very unhappy situation.   My interest in JSON is to consume data
> in JSON documents (mostly to use as input into representation systems that
> also use the W3C semantic web languages RDF and OWL). If JSON is ambiguous
> (e.g., as to whether 0.0 and 0 encode/stand for/represent the same thing)
> then JSON isn't very suitable for transmitting data, at least for me.

While i think we will all agree that, at a technically pedantic level,
you're absolutely right, JSON has been in heavy use for about 10(?) years
now with _relatively_ few instances of this causing a problem. Implementors
tend to use whatever default limits the platform provides (e.g. 32-bit on
32-bit platforms and 64 on 64-bit, and 6-digit precision in doubles seems
to be conventional in C libraries). People using high-precision/very
large/very small numbers are certainly aware of the limitations/portability
problems, and will (possibly after falling on their face with JSON) pick a
different format. That's all fine and good - i haven't seen anyone here
argue that JSON needs to be _the_ data format. It needs to be a _useful_
format for a wide range of applications, and it is that even if it's
hard-coded to be limited to 31-bit integer ranges. In my implementations i
have had to be very aware of system-level precision limits, but i simply
document them, add build options to use, e.g. 64-bit integers if available,
and leave it at that. Those details fall comfortably into the normal range
of "implementation defined" details, IMO, and do _not_ (IMO) fall into
JSON's realm of authority (JSON just needs to tell me the BNF for reading a
number, though one could argue that the BNF should/does also imply certain
limits). It would be impossible to enforce that arbitrary implementations
must support arbitrarily long numbers, just as it would be silly to
arbitrarily limit JSON to, say, 20-bit precision.

Using your case of 0 vs 0.0. The vast, vast majority of JSON consumers are
JavaScript, and JS doesn't differentiate between doubles and integers, so 0
is, in effect equivalent to 0.0. In fact, there are few real-world
applications using JSON where the two are _not_ equivalent (barring
scientific, high-precision, math-centric apps, of course, and those should
probably be looking for a different format which guarantees them their
desired ranges/limits).

----- stephan beal