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: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
