Just to quickly chime in, I basically agree with what's already been said here. Philosophically, we wanted to constrain the set of built-in Thrift types to only those that are very common across all programming languages. This, for instance, is why we even decided against supporting unsigned integers.
Though similar datetime implementations do exist in many languages, there is no real standard for how to represent a datetime in all programming languages, or over the network. Thrift would be sort of inventing a type here. Most languages that do support a datetime type of some sort offer very simple APIs to construct datetime objects from milli/micro-second counters. In my opinion, if you're not bundling timezone info in them, datetime objects offer little benefit over using milli/micro-seconds since the epoch. And supporting timezones in any form is something I'd definitely rather not ever see pushed down into the Thrift layer. Cheers, Mark -----Original Message----- From: Matthieu Imbert [mailto:[email protected]] Sent: Wednesday, October 28, 2009 12:49 PM To: [email protected] Subject: Re: datetime type in thrift 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 i use this: struct Timestamp { 1: i32 s = -2147483648, 2: i32 micro_s = 0, } -- Matthieu
