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 <[email protected]>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. > >
