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
