Hi,
at first: I'm new to thrift. Thus I maybe do not understand the design
patterns of thrift and thus cannot understand the problems Ben Craig
pointed out.
However, I want to disagree and would suggest a solution. If a descision
is made, of course I would help to implement. If one complain one have
to make it better ;).
My suggestion: the unix timestamp. It would be a i64 in thrift.
Am 23.08.2013 20:14, schrieb Jens Geyer:
> Agree. A few points again, though.
>
> • double or i64 for the wire format, depending on whats best for the
> majority of languages. Strings or smaller ints are obviously not
> suitable.
well. Long would work.
> • the wire format needs a well-defined null point,
which would be a monday in 1970.
> depending on whats
> best for the majority of languages, so that the need for rebasing a
> timestamp from one system into another can be avoided as much as
> possible
here I would disagree. The thrift community is a community on it's own.
It can make an impact on making the existing and good standard more ...
standard ;).
Every modern operating system is more or less POSIX, and thus has the
"time" function from c (POSIX level 1), thus every language can achieve
the unix timestamp. The rest is a little conversion to the nativ format.
> • interpretation of the timestamp value (utc? time zone offsets?
> summer/winter?) is to be handled by application. That's nothing
> thrift should do.
agreed.
> • how about time spans?
this is a question of application logic, not a problem thrift has to
encounter.
If you have:
struct Example {
1: i32 id;
2: datetime start;
3: datetime end;
};
or
struct Example {
1: i32 id;
2: datetime start
3: datetime duration
};
should be the same for thrift. It's a question of logic in the application.
> • for the reasons above, especially the first two points, I suggest
> that we first try to find out what time system should be used for the
> wire format by collecting the preferred ones for each language
done ;).
And for the thread author: I would go with i64 and just use the time()
function (or equivalent functions) and other related methods.
Best
Wilm
ps: and 2038 it should be changed anyway ;)
