You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by Rudi Benkovič <ru...@whiletrue.com> on 2011/07/06 01:49:28 UTC
json date representations
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
Re: json date representations
Posted by Rudi Benkovic <ru...@whiletrue.com>.
Hello Max,
Wednesday, July 6, 2011, 2:23:12 AM, you wrote:
> ISO8601 is the preferred format because it sorts lexicographically, which
> makes it super easy to sort views by date. The JSON.stringify method in
> json2.js automatically converts javascript date objects to ISO8601 and
Ecmascript >> 1.4 (iirc) natively supports parsing ISO8601
> tl;dr always use ISO8601
Some alternatives that are produced by the Newtonsoft JSON serializer:
1) "LogDate":"\/Date(1234656000000)\/"
2) "LogDate":new Date(1234656000000)
3) "LogDate":"2009-02-15T00:00:00Z"
Unfortunately, 1) is actually the default unless ISO serialization is
explicitly specified, as in 3). Hence, my little survey about what other weird
formats might be out there. :)
--
Best regards,
Rudi mailto:rudib@whiletrue.com
Re: json date representations
Posted by Max Ogden <ma...@maxogden.com>.
ISO8601 is the preferred format because it sorts lexicographically, which
makes it super easy to sort views by date. The JSON.stringify method in
json2.js automatically converts javascript date objects to ISO8601 and
Ecmascript > 1.4 (iirc) natively supports parsing ISO8601
tl;dr always use ISO8601
On Tue, Jul 5, 2011 at 5:05 PM, Patrick Barnes <mr...@gmail.com> wrote:
> I use ISO8601 as well; "2010-08-29T13:07:49+10:00"
> (generated using PHP date('c');)
>
>
> On 6/07/2011 9:49 AM, Rudi Benkovič wrote:
>
>> 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
>>
>>
Re: json date representations
Posted by Patrick Barnes <mr...@gmail.com>.
I use ISO8601 as well; "2010-08-29T13:07:49+10:00"
(generated using PHP date('c');)
On 6/07/2011 9:49 AM, Rudi Benkovič wrote:
> 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
>
Re: json date representations
Posted by "Mark J. Reed" <ma...@gmail.com>.
On Wed, Jul 6, 2011 at 3:44 PM, Randall Leeds <ra...@gmail.com>wrote:
> On Wed, Jul 6, 2011 at 12:08, Mark J. Reed <ma...@gmail.com> wrote:
> > On Wed, Jul 6, 2011 at 2:12 PM, Mark Hahn <ma...@boutiquing.com> wrote:
> >
> >> Who decided months should be zero-based but not days?
> >>
> >
> > Not sure who the author was, but the motivation is that the month (and
> > weekday) number is expected to be used to index into an array of names,
> and
> > arrays are 0-based. The day of the month is not an index into a list, so
> it
> > survives unmolested.
>
> Not true in a lot of languages (notably here: Erlang).
>
True, but not really relevant, as calendar:local_time/0 also returns months
numbered from 1. :)
Sorry for taking this thread off-track; I started off discussing the
limitations of JSON and the various choices in representing dates, and how
it would in many cases be more convenient, when deserializing into
JavaScript, to take advantage of JavaScript syntax not normally allowed in
JSON for creating actual Date objects. Which led to a tangent about the
options for constructing such objects in JavaScript still not being terribly
easy to read for humans...
--
Mark J. Reed <ma...@gmail.com>
Re: json date representations
Posted by Randall Leeds <ra...@gmail.com>.
On Wed, Jul 6, 2011 at 12:08, Mark J. Reed <ma...@gmail.com> wrote:
> On Wed, Jul 6, 2011 at 2:12 PM, Mark Hahn <ma...@boutiquing.com> wrote:
>
>> Who decided months should be zero-based but not days?
>>
>
> Not sure who the author was, but the motivation is that the month (and
> weekday) number is expected to be used to index into an array of names, and
> arrays are 0-based. The day of the month is not an index into a list, so it
> survives unmolested.
Not true in a lot of languages (notably here: Erlang).
>
> We're also ignoring the fact that the year is internally stored less 1900;
> the get[UTC]FullYear() method hides that, and the constructor uses a
> heuristic to decide whether or not to add 1900 to its first argument.
>
>
>
>> On Wed, Jul 6, 2011 at 8:15 AM, Mark J. Reed <ma...@gmail.com> 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 <juanjo@comellas.org
>> >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č <ru...@whiletrue.com>
>> >>
>> >> > 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 <ma...@gmail.com>
>> >
>>
>
>
>
> --
> Mark J. Reed <ma...@gmail.com>
>
Re: json date representations
Posted by "Mark J. Reed" <ma...@gmail.com>.
On Wed, Jul 6, 2011 at 2:12 PM, Mark Hahn <ma...@boutiquing.com> wrote:
> Who decided months should be zero-based but not days?
>
Not sure who the author was, but the motivation is that the month (and
weekday) number is expected to be used to index into an array of names, and
arrays are 0-based. The day of the month is not an index into a list, so it
survives unmolested.
We're also ignoring the fact that the year is internally stored less 1900;
the get[UTC]FullYear() method hides that, and the constructor uses a
heuristic to decide whether or not to add 1900 to its first argument.
> On Wed, Jul 6, 2011 at 8:15 AM, Mark J. Reed <ma...@gmail.com> 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 <juanjo@comellas.org
> >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č <ru...@whiletrue.com>
> >>
> >> > 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 <ma...@gmail.com>
> >
>
--
Mark J. Reed <ma...@gmail.com>
Re: json date representations
Posted by Keith Gable <zi...@ignition-project.com>.
In JavaScript, the native date representation is the number of milliseconds
since the Unix Epoch. I assume this applies in JSON/CouchDB.
On Jul 6, 2011 1:52 PM, "Peter Nolan" <pe...@gmail.com> wrote:
> Not to hijack the thread, but what is couchdb's standard for dates? For
> example, if i save a doc with a field of date:new Date()
> what is the format that the date is saved in the couchdb doc?
> And is there a script available to convert any date object to this format?
>
> Thanks,
>
> -Pete
Re: json date representations
Posted by Peter Nolan <pe...@gmail.com>.
Not to hijack the thread, but what is couchdb's standard for dates? For
example, if i save a doc with a field of date:new Date()
what is the format that the date is saved in the couchdb doc?
And is there a script available to convert any date object to this format?
Thanks,
-Pete
Re: json date representations
Posted by Mark Hahn <ma...@boutiquing.com>.
Who decided months should be zero-based but not days?
On Wed, Jul 6, 2011 at 8:15 AM, Mark J. Reed <ma...@gmail.com> 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 <ju...@comellas.org>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č <ru...@whiletrue.com>
>>
>> > 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 <ma...@gmail.com>
>
Re: json date representations
Posted by "Mark J. Reed" <ma...@gmail.com>.
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 <ju...@comellas.org>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č <ru...@whiletrue.com>
>
> > 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 <ma...@gmail.com>
Re: json date representations
Posted by Juan Jose Comellas <ju...@comellas.org>.
I know, but the ISO 8601 format is much bulkier, and when you store hundreds
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 <rn...@apache.org> 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 <ju...@comellas.org> 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č <ru...@whiletrue.com>
> >
> >> 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
> >>
> >
>
Re: json date representations
Posted by Robert Newson <rn...@apache.org>.
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 <ju...@comellas.org> 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č <ru...@whiletrue.com>
>
>> 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
>>
>
Re: json date representations
Posted by Juan Jose Comellas <ju...@comellas.org>.
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č <ru...@whiletrue.com>
> 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
>