On 04/07/2010 10:23 AM, Andrew Stitcher wrote:
On Wed, 2010-04-07 at 09:22 -0400, Alan Conway wrote:
On 04/06/2010 10:29 PM, Andrew Stitcher wrote:
On Tue, 2010-04-06 at 15:33 -0400, Alan Conway wrote:
I need to (de)serialize AbsTime timestamps. I can convert an AbsTime to a
uint64_t with uint64_t(Duration(abstime)) but I don't see how to convert back to
an AbsTime. I can just add a constructor but wanted to check with you if I'm
missing the intent.
The problem here is that fundamentally the class is designed not to show
it's epoch value. The fact you can wheedle it out by going via a
Duration is not intentional!
[BTW Duration& AbsTime encapsulate an int64_t so using uint64_t is
incorrect. Both are allowed to be negative - Duration -ve indicates
before the time you asked about, AbsTime -ve indicates before the Epoch]
The external representation can't simply be the nanosec count in AbsTime
as different platforms have different Epochs. This is certainly true
between Windows and Unix.
I guess there needs to be an explicit way to convert a specific
date/time to an AbsTime so that you can use the existing differencing
operations as you can get a Duration out of the difference between the
AbsTime you're serialising and some fixed Epoch AbsTime. And equally you
can construct an AbsTime out of an Epoch AbsTime and a Duration.
Actually I suppose you could just declare a new static AbsTime as the
Epoch and make sure it represents the same time across all platforms.
Then use it for serialisation. That would avoid needing to do the
general Date->AbsTime thing.
This has rambled a bit, get back to me if it's not clear, I could add an
Epoch AbsTime for you if it's not clear how to do it fairly easily.
Here's a patch to add an EPOCH constant to Time.h, Steve can you check that I've
got the windows part right?
Minor Quibbles:
To be consistent with the other constant(s) in the file "Epoch" would be
better than the all capitalised version.
Similarly for consistency, it might be better to use a member function
Epoch() - like FarFuture() which is also a constant. I admit I can't
remember why it's not a simple constant. but why not just be consistent
with it?
Agreed, will do that.
Incidentally, does c++ guarantee that global constant POD classes like
AbsTime have their members 0 initialised? The Posix code relies on it,
but I can't remember that little niche of behaviour at this moment
(without my copy of the standard here). Probably wise to comment to that
effect before the definition if so.
POD data isn't 0 initialized unless it has an = 0 initializer. And in the
windows version I'm initializing with a function call so that's not guaranteed
to happen before other stuff in static initializers. If I change this to a
function then I can drop the global constant and we won't have to worry about it.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
