Who decided months should be zero-based but not days?
On Wed, Jul 6, 2011 at 8:15 AM, Mark J. Reed <[email protected]> wrote: > It's all about the use case, right? In a couchdb app, your map functions > can convert readily among formats, but it probably makes sense to use the > form that requires the least work from your most commonly-used views. > > When using JSON as a serialization format, something that constructs an > actual JavaScript Date object would often be preferable to something that > requires extra code to process the objects later. But something like "new > Date(1310000000000)" loses the benefit of JSON being human-readable. The > multiple-argument constructor forms, as in "new > Date(Date.UTC(2011,6,7,0,53,20))", would be a nice compromise were it not > for the use of 0-based month numbers (that's July, not June). > > On Wed, Jul 6, 2011 at 10:53 AM, Juan Jose Comellas > <[email protected]>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č <[email protected]> >> >> > 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 >> > >> > > > > -- > Mark J. Reed <[email protected]> >
