couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Hahn <>
Subject Re: Sorting dates in CouchDB
Date Mon, 08 Oct 2012 23:48:38 GMT
It's obviously a personal call.  Personal to the developer and personal to
the specific app needs.  It would be interesting to have a poll, just out
of curiosity.

On Mon, Oct 8, 2012 at 4:44 PM, Kai Griffin <>wrote:

> On 08/10/2012 22:14, Mark Hahn wrote:
>> so I've always just felt more comfortable having them stored as dates to
>> begin with so there's no additional conversion process to extract those
>> year, month, etc values.
>> Whether you use numbers or strings it still needs to do a conversion from
>> json (a string) to a Date object.  For that matter it might be slower to
>> convert from the JSON number in a string to a Date than from a string to a
>> Date.  I have no idea of course.
>> I just realized I was thinking of code in the client.  Using a number for
>> a
>> key lookup is probably faster.  I wonder if Couch stores the JSON as a
>> string in the DB or converted to binary.
> First of all, having now browsed this topic of dates-as-strings vs
> dates-as-long-ints a little bit, I didn't realise until now that storing
> full date strings in this context is fairly commonplace, even in text
> books.  It suggests that many of my assumptions about performance might be
> ill-founded.  I still struggle to see how "new Date(dateString)" could be
> as speed-efficient as "new Date(milliseconds)" within a map function, but
> this only impacts view creation (and only if you actually have to
> instantiate a date object like that), so the penalty is paid only once per
> document (but in my case this is tens of millions of documents, so it still
> might be a big enough penalty to worry about).
> I guess as a storage-space miser (and admittedly also on a philosophical
> level), I still personally prefer that dates, representing as they do
> milliseconds, remain numbers in storage, and  come to life only fleetingly
> as long, readable strings at run-time on the client-side.  Even if the
> numeric version is stored as a string internally within JSON/couch, it's
> still less than half the size of the equivalent full date string.  This
> doesn't help with reading Futon or log files, admittedly.  In my own case,
> I have several different kinds of date-time values in each document, and
> over 30 million documents, growing daily - the storage space difference
> between numeric and full-string versions of dates would definitely be
> significant.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message