Return-Path: X-Original-To: apmail-couchdb-user-archive@www.apache.org Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id A2F0662A5 for ; Wed, 6 Jul 2011 15:14:53 +0000 (UTC) Received: (qmail 10214 invoked by uid 500); 6 Jul 2011 15:14:52 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 10166 invoked by uid 500); 6 Jul 2011 15:14:51 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 10157 invoked by uid 99); 6 Jul 2011 15:14:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2011 15:14:51 +0000 X-ASF-Spam-Status: No, hits=2.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_SOFTFAIL X-Spam-Check-By: apache.org Received-SPF: softfail (nike.apache.org: transitioning domain of juanjo@comellas.org does not designate 209.85.161.44 as permitted sender) Received: from [209.85.161.44] (HELO mail-fx0-f44.google.com) (209.85.161.44) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 06 Jul 2011 15:14:45 +0000 Received: by fxe6 with SMTP id 6so190540fxe.31 for ; Wed, 06 Jul 2011 08:14:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.7.8 with SMTP id b8mr13516419fab.19.1309965264442; Wed, 06 Jul 2011 08:14:24 -0700 (PDT) Received: by 10.223.114.5 with HTTP; Wed, 6 Jul 2011 08:14:24 -0700 (PDT) In-Reply-To: References: Date: Wed, 6 Jul 2011 12:14:24 -0300 Message-ID: Subject: Re: json date representations From: Juan Jose Comellas To: user@couchdb.apache.org Content-Type: multipart/alternative; boundary=00151747858241565704a7680e67 X-Virus-Checked: Checked by ClamAV on apache.org --00151747858241565704a7680e67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I know, but the ISO 8601 format is much bulkier, and when you store hundred= s of millions of records with a minimum of two timestamps per document, it quickly adds up. Besides, it makes it much easier to make timestamp calculations in the views. Juanjo On Wed, Jul 6, 2011 at 12:02 PM, Robert Newson wrote: > ISO 8601 allows nanosecond precision; > > "Decimal fractions may also be added to any of the three time > elements... A fraction may only be added to the lowest order time > element in the representation... There is no limit on the number of > decimal places for the decimal fraction" > > B. > > On 6 July 2011 15:53, Juan Jose Comellas wrote: > > We use CouchDB for a telephony application where we sometimes need > subsecond > > precision, so we store timestamps as floating point numbers, where the > > integer part corresponds to the seconds and the decimal part to the > > {milli,micro,nano}seconds since the Unix epoch (Jan 1, 1970). The nice > thing > > about this format is that it can be used both for absolute (a date) and > > relative (the offset at which an event occurred) timestamps and you can > > easily perform arithmetic operations between them. > > > > > > 2011/7/5 Rudi Benkovi=C4=8D > > > >> Hi, > >> > >> I'm writing a little CouchDB administration utility and would like to > >> find out how most of you store data values in JSON. From .NET via > >> Newtonsoft's JSON serializer, dates end up in the ISO 8601 as a > >> string, like this: > >> > >> { Timestamp": "2011-05-12T20:52:02.3774261Z" } > >> > >> Let me know what other formats are used, as I'd like to cover as much > >> of them as possible - hopefully the Javascript view code will be able > >> to detect them automatically. > >> > >> Thanks! > >> > >> Rudi > >> > > > --00151747858241565704a7680e67--