Gordon, Many thanks.
Yes, other parts of our system are probably using the JMS client, and that's where I suspect my millisecond numbers are coming from. I think I'll go with my work-around, if if, in the year 10000 or so someone is unhappy, they'll just have to dig me up. Bill On Tue, Apr 1, 2014 at 5:22 PM, Gordon Sim <[email protected]> wrote: > On 04/01/2014 10:03 PM, Bill Freeman wrote: > >> I'm receiving messages using the python qpid.messaging API, and getting a >> value for x-amqp-0-10.timestamp that is an instance of >> qpid.datatypes.timestamp, and whose value, when coerced to a str (print) >> or >> to a float, is apparently miliseconds since the Unix epoch. >> >> Yet looking at the implementation of qpid.datatypes.timestamp, it appears >> to expect to hold units of seconds since the epoch, based on the fact that >> if you call it with arguments it initializes from time.time(), or it can >> be >> passed a datetime..datetime object which it correctly converts to seconds >> since the epoch. It also performs add and subtract using >> datetime.timedelta. >> >> So if I use time.localtime on one of these timestamps, I'm seeing years >> like 46210. >> >> (Using qpid_python-0.20 and a probably older C++ bfoker.) >> >> Now, I don't think that these timestamps are being added by the broker >> (contrary to some documentation I've seen) since if I post a simple >> message >> with spout, I don't get an x-amqp-0-10.timestamp property. So the times >> in >> miliseconds could be a problem with the software generating the messages. >> >> I have a couple of questions, then. >> >> 1. Are there official units for AMQP 0.10 timestamps? (seconds versus >> milliseconds) >> > > The datetime type in 0-10 is specified to be in 'POSIX time_t format' > which is seconds, as you point out. > > > 2. Is generation of an x-amqp-0-10.timestamp by the broker an option (for >> an older C++ broker, probably 0.14). >> > > Yes, the broker option --enable-timestamps can be used to cause the broker > to timestamp each message. However there is some impact on performance from > that if I recall correctly, which is why it is off by default. > > > Particularly, is there a way for the >> client to send a message that does this, but which spout doesn't do, >> rather >> than a broker re-configuration? >> > > No, its a broker level rather than message level option. However the JMS > client uses that field for its own use (and may be the source of the > millisecond based value you are seeing?) > > > 3. If the broker does generate the timestamp, what will the units be? >> > > Seconds since the Epoch. > > > (My current action plan is to compare the timestamp to 253402318800.0, >> which is the year 10000 in seconds after the epoch, consider it to be >> miliseconds if greater, and in seconds if less. That means that I will >> misinterpret millisecond timestamps for earlier tan Jan 11, 1978, 16:32 or >> so, that I will misinterpret seconds timestamps for later than the year >> 10000. I think that I can live with those.) >> >> Bill >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
