I'm not saying this isn't doable -- opening a ticket and submitting a patch will go a lot longer than just discussing on the list. I am saying that a common concern when introducing types into Thrift is that we need to find the correct representation in all languages. And I was also pointing out some of the problems with representing date time in particular, like time zones.
On Fri, Aug 23, 2013 at 11:10 AM, Andrew Pennebaker <[email protected]>wrote: > Any particular language's implementation of datetimes wouldn't preclude a > common Thrift datetime data type, just like any language's other types > don't preclude Thrift equivalents. Even with ms rather than us resolution, > Windows and Linux still get along together. > > Any language-specific Thrift library would just automatically encode/decode > a datetime between Thrift and that language's datetime structure. > > > On Fri, Aug 23, 2013 at 10:16 AM, Carl Yeksigian <[email protected]> > wrote: > > > The problem with a datetime data type is that it isn't supported in all > > languages (Java, for example, has a poorly implemented Date class which > > they are changing in 1.8, C# just went through a switch because the > > original implementation didn't account for time zones). I'm not even sure > > what the standard implementation would be in a C or C++ program. Since we > > don't want to be responsible for a time library, it doesn't really make > > sense to include this in the base library. > > > > For us, we have found modeling the date time after the language that we > > primarily use (in our case, we are using C#), and then writing a thin > > wrapper around handling in other languages (Java for example) is much > > easier for us. > > > > Our date time implementation, modeled after the data that is captured by > > DateTimeOffset ( > > http://msdn.microsoft.com/en-us/library/system.datetimeoffset.aspx): > > struct TDateTimeOffset { > > /** > > * Number of ticks since midnight (12:00:00) on January 1, 0001 > > */ > > 1: required i64 ticks, > > /** > > * Number of minutes from UTC to this date time > > */ > > 2: required i16 utcOffset, > > } > > > > > > On Fri, Aug 23, 2013 at 9:06 AM, Andrew Pennebaker < > [email protected] > > >wrote: > > > > > ... which is why Thrift needs a datetime data type. > > > > > > > > > On Fri, Aug 23, 2013 at 2:56 AM, Jens Geyer <[email protected]> > > wrote: > > > > > > > String may involve conversion and parsing. > > > > ________________________________ > > > > Von: nosql-菜鸟 > > > > Gesendet: 23.08.2013 08:31 > > > > An: user; user > > > > Betreff: 回复：AW: Datetime data type in Thrift? > > > > > > > > you can use string or i32. string is better. > > > > > > > > > > > > > > > > > > > > ------------------ 原始邮件 ------------------ > > > > 发件人: "Jens Geyer"; > > > > 发送时间: 2013年8月23日(星期五) 凌晨1:59 > > > > 收件人: "user"; > > > > 主题: AW: Datetime data type in Thrift? > > > > > > > > > > > > > > > > No, the recommendation is to use double or i64. The biggest challenge > > is > > > > to find consensus on the timestamp base. Especially across platforms. > > > > > > > > Btw, all available data types can be found on the website at > > > > thrift.apache.org > > > > > > > > Protobuf: dont know. > > > > ________________________________ > > > > Von: Andrew Pennebaker > > > > Gesendet: 22.08.2013 18:51 > > > > An: Thrift Users > > > > Betreff: Datetime data type in Thrift? > > > > > > > > Could there be a Thrift data type for datetimes? Integrating > different > > > > datetime formats across systems can be really helpful. > > > > > > > > If not, do Protocol Buffers have a datetime data type? > > > > > > > > > >
