Is there an advantage to Mongo Date vs. UNIX Timestamp?

[james33]

Is there any sort of advantage (performance, indexes, size, etc) to
storing dates in MongoDB with Date() vs. storing a regular UNIX
timestamp?

[james33]

And by Date(), I mean ISODate().

[วชิราวุธ ธรามวิเศษ]

If you use Unix Timestamp , it will be store in  Number.  How do you know that number is date or not.?

2011/6/13 james33 <jam...@gmail.com>

--
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To post to this group, send email to mongod...@googlegroups.com.
To unsubscribe from this group, send email to mongodb-user...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mongodb-user?hl=en.

[Gates]

It looks like you have cross-posted this one:
http://stackoverflow.com/questions/6332975

Typical UNIX timestamps are represented by a 32-bit int.
If you're planning to save 32-bit timestamps, you're on your own to
convert them to/from actual dates.

As defined in the BSON spec, the ISODate() is a 64-bit int.
http://bsonspec.org/#/specification
Most drivers convert native Date objects into the 64-bit MongoDB
dates.

So, to your question:
> Is there any sort of advantage...

There is a trade-off here. Bigger data type vs smaller data type.

If you don't care about the 8 bytes, "dates" are probably easier to
work with.

If you really care about the 8 bytes, just keep an eye out for 2038 :)

- Gates

On Jun 13, 9:42 am, วชิราวุธ ธรามวิเศษ <twach...@gmail.com> wrote:
> If you use Unix Timestamp , it will be store in  Number.  How do you know
> that number is date or not.?
>

> 2011/6/13 james33 <jame...@gmail.com>

[Tal Liron]

I'll add one important thing to take note of --

When working with MongoDB, JSON (or MongoDB's extended JSON notation)
is used a lot to serialize or otherwise represent the data.

The problem is that true JSON, based on JavaScript, does not have
integers of any kind, only floating point numbers. Many JSON
implementations are actually not strict, and quite relaxed, so
depending on your language and driver you might not notice any
difference. However, an 8-byte integer will lose precision if
converted to an 8-byte float by your JSON implementation. This can be
seconds and even minutes off.

This is immediately apparent if you work in JavaScript, using the
MongoDB console or the Rhino driver (which I wrote), which both use
strict JSON due to the nature of being JavaScript!

My solution was to introduce a new extended JSON notation:
$long:'string', which allows for storing 8-byte integers as string
representations in JSON. In the Rhino driver, a check is made first
that precision would indeed be lost before using the $long notation.
And the driver does know how to translate it back to an integer for
true 1-to-1 serialization. (The console is able to represent dates
correctly, but I don't know if it can consume them back.)

There is no easy way to work natively with long integers in JavaScript
beyond simple equality test. BigDecimal libraries may be the best
choice for such situations.

On Jun 13, 1:13 pm, Gates <ga...@10gen.com> wrote:
> It looks like you have cross-posted this one:http://stackoverflow.com/questions/6332975
>
> Typical UNIX timestamps are represented by a 32-bit int.
> If you're planning to save 32-bit timestamps, you're on your own to
> convert them to/from actual dates.
>

> As defined in the BSON spec, the ISODate() is a 64-bit int.http://bsonspec.org/#/specification

> Most drivers convert native Date objects into the 64-bit MongoDB
> dates.
>
> So, to your question:
>
> > Is there any sort of advantage...
>
> There is a trade-off here. Bigger data type vs smaller data type.
>
> If you don't care about the 8 bytes, "dates" are probably easier to
> work with.
>
> If you really care about the 8 bytes, just keep an eye out for 2038 :)
>
> - Gates
>