using google.protobuf.Timestamp in c/c++

kgw56

Hi,
I use time_t for google.protobuf.Timestamp in implementation, but doesn't seem to me that it works out well. eg. i put time t t3 = 1621435475, is Wed May 19 10:44:35 2021, but the solace server return time t as, 140723368189072, is Tue Jan 7 03:57:52 4461316, which is garbage.
Do you have any idea why?
Thanks.

Tamimi

Hey @kgw56 ! Welcome to the Solace Community. Can you put more details and code snippet on how you are using this and we can potentially help out?

amackenzie

Yes, for instance what are you using on the Solace client to deserialize the protobuf in the nessage payload? The Solace APIs are payload agnostic.

kgw56

What do you mean by that? the definition of transactiontime on both executionreport.pb.h and executionreport.pb.c are standard from ./protoc -I=. --cpp_out=. executionreport.proto.
Please give me the details on what you're trying to say.
Thanks

amackenzie

I guess I am like @tamimi and don't understand what it is you are trying to do. Can you give some more details?

kgw56

I thought that i had provided all the details.
We have a solace server and executionreport.proto to use by both publisher app to send msg to solace server and subscriber to get the msg from solace server.
1) In executionreport.proto,
we message ExecutionReport {
string id=1;
...
google.protobuf.Timestamp transactTime = 6;
}
2) ./protoc -I=. --cpp_out=. executionreport.proto.
3) In protobufmessage.h we have class ExecutionReportMessage
{
public:
string id;
....
time t transactTime;
}
4) In publisher app, we setup transactTime = 1621435475, id = ABC. In subscriber app, we get transactTime = 1140723368189072, id = ABC.... NOT transactTime = 1621435475... do you know why? because id = ABC is correct on subscriber. Why transactTime is not Correct? Also, all the other fields are correct except transactTime... It seems that google.protobuf.Timestamp doesn't work well here.

Let me know what else you're not clear.
Thanks,

amackenzie

maybe others do, but I don't know what ExecutionReport.proto is. Is it some telemetry you are publishing to a message body/payload? My point above was that PubSub+ does nothing with payloads so if you put a protobuf serialized message including the timestamp you mentioned to the server, when it's consumed via the subscriber client, the payload will not be altered by PubSub+. If the values are not the same on the consumer after deserialization then there is something wrong with the deserialization app.

amackenzie

for instance, is google.protobuf.Timestamp the equivalent to time in C?

kgw56

Thanks for your response. Ok we have an ExecutionReport class in proto file, with field as google.protobuf.Timestamp transactTime = 6; // In seconds, using on both subscriber and publisher. In ProtoBufMessage.H, we have class ExecutionReportMessage, with field as time_t timeStamp, for the transactTime. On publisher, it puts time t t3 = 1621435475, which is Wed May 19 10:44:35 2021. On the subscriber, I got time t timeStamp, as 140723368189072, is Tue Jan 7 03:57:52 4461316, which is garbage, because I expect to get the same number as 1621435475, from publisher.

Q: Should I declare, time t for google.protobuf.Timestamp transactTime ?
on Publisher: (setup to sent transactionTime)
time_t t1, t3;
struct tm *t2;

t1 = time(NULL);
t2 = localtime(&t1);
t2->tm_hour = hh;
t2->tm_min = mm;
t2->tm_sec = ss;
t3 = mktime(t2);
msg.setTimeStamp( t3 );
on subscriber: ( show the transactionTime from publisher)
os << "Timestamp: " << msg.getTimeStamp() << endl;
time_t ltime = msg.getTimeStamp();
os << "Timestamp2: " << ctime( &ltime ) << endl;

Let me know if it's enough detail.
Thanks,

Tamimi

It might be the implementation of getTimeStamp on the subscriber side which is independent from the underlying broker infrastructure. Think of the PubSub+ as a channel to transport your data with no payload manipulation as @amackenzie mentioned. If you serialize your message on the publishing side and added a time stamp, you should get the same content on the subscriber side if you use the same deserialization process to extract the message content (including the timestamp).