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)
2. Is generation of an x-amqp-0-10.timestamp by the broker an option (for
an older C++ broker, probably 0.14). 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?
3. If the broker does generate the timestamp, what will the units be?
(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
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)
2. Is generation of an x-amqp-0-10.timestamp by the broker an option (for
an older C++ broker, probably 0.14). 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?
3. If the broker does generate the timestamp, what will the units be?
(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
