Search code examples
c#c++ccommunicationthrift-protocol

Which Data Type is most appropriate for datetime in thrift communication in c++?

In thrift communication I need to send Date and Time from client to server. so which datatype will be most appropriate.

My Client is in C++ and Server is in C-Sharp. and in Server I am using DateTime keyword for doing this task. but Confused about Cpp that What I should use because I64 which I am using right now is not giving me the correct data at server side.

Thanks in Advance

Solution

  • I think Konrad's comment is probably the accurate short answer, you need to make sure that the C++ i64 has the same meaning as the C# i64. The .Net DateTime uses Windows tick counts (100 nano second intervals since 1601). Your C++ code may be expecting seconds since 1970. Read on...

    Cross platform Date/Time presents several challenges. There are numerous system interfaces, distinct programming language facilities and various ways to encode date/time. In most cases systems and languages don’t try to provide compatibility with each other.

    To get a sense for the range of possibilities:

    • Gnu Linux supports struct timeval (usec resolution), struct timespec (nsec resolution), time_t (second resolution), struct tm (date/time broken down), among others, more info here: ftp://ftp.gnu.org/old-gnu/Manuals/glibc-2.2.3/html_chapter/libc_21.html
    • Windows uses SYSTEMTIME, FILETIME and LARGE_INTEGER for high resolution timers.
    • C++98 inherits time() from C but C++11 supplies the std::chrono library
    • .Net supplies the DateTime structure and other features

    If you want to deal with dates and times across platforms it can be beneficial to select a “pivot format”, a format that all of your code relies on when communicating date/time externally (for example, with Apache Thrift).

    Converting to/from a pivot format (or any other specific format) is something you need to do actively. It is uncommon for any two systems to supply compatible structures and semantics.

    For example, POSIX and Windows both produce a 64 bit integer housing the elapsed time since an epoch but the granularity (units of time) and epoch (starting point) are different. Windows GetSystemTimeAsFileTime() returns a FILETIME storing the 64-bit number of 100-nanosecond intervals since midnight Jan 1, 1601 and the POSIX time() function returns the number of seconds that have elapsed since Jan 1, 1970. Also some systems define fields that exceed their clock granularity. Windows GetSystemTime() reports values to the millisecond but is generally accurate to only about 10 milliseconds. Add to this timezones, leap seconds and other anomalies and you are really taking a flyer if you just copy bits from one struct to another or reinterpret a pointer without carefully considering the source and the destination.

    An explicit struct is often clearer than an implicit elapsed-unit/epoch integral value for general purpose communication of time stamp style data. For example, something like this might work for a Thrift RPC application:

    struct TimeStamp {
  1: i16 year
  2: byte month
  3: byte day
  4: byte hour=0
  5: byte minute=0
  6: i16 second=0
  7: double fraction=0
}

    If you want to be able to do math with your timestamps (e.g. subtract two timestamps to find an elapsed time) then an integral value (like i64) may be better but you will still need to establish a pivot format and carefully manage conversions from platform to platform and language to language to address granularity and epoch at a minimum.

    One nice thing about the JVM and .Net/CLR environments is that you can use the respective platform libraries from any language on the platform. Thus if you use managed C++ your C++ code will have access to the same mscorlib.DateTime as the C# server.