Our definition of 'timestamp' is a bit clunky, yes. We're using
millisecond resolution because this happened to map well into our
service implementation (in Java).
Ignoring the milliseconds is even more embarrassing -- we're storing the
times in MySQL, which can't handle sub-millisecond resolution in its
date/time fields. (We found this out too late to resolve easily, etc.)
Michael Greene wrote:
We are using microseconds-since-epoch here. One downside to this
approach from an interop perspective is the ease at which Java,
Javascript, and UNIX in general deal with milliseconds-since-epoch vs.
microseconds. If I didn't need microseconds for business reasons, I
would use milliseconds. When I asked around on #thrift awhile back,
that was the most common approach.
Michael
On Wed, Oct 28, 2009 at 1:29 PM, David Reiss <[email protected]> wrote:
I would suggest doing something similar to what Evernote is doing.
(Though if you're using an i64, you might as well use microseconds.)
--David
Ted Yu wrote:
From my experience working with web services using SOAP in PHP and Java,
datetime handling is a source of big headache.
Is there plan for thrift to add datetime type support ?
I see alternative such as:
http://www.evernote.com/about/developer/api/ref/Types.html#Typedef_Timestamp
Regards
