[date_time][serialization] Fast persistence of boost::date_time::ptime
I am interested in serializing data structures like vector< pair< boost::date_time::ptime , double> > as quickly as possible. I see that ptime is a serializable object (in the Boost.Serialization sense) but on the surface this implementation looks slow - we first get a date and time_duration and then serialize the various components (mins,secs,subsecs) separately for the latter and construct a full ISO string for the date. Something faster is surely possible - digging into the implementation it looks like a (non-special) ptime is represented as boost::uint64_t so if we were privy to all implementation details we could use serialize that. However on this glance this doesn't seem possible non-intrusively. Perhaps I've missed something, perhaps there's a third way - I would be grateful if any could share any ideas. Thanks, Pete
However on this glance this doesn’t seem possible non-intrusively. Perhaps I’ve missed something, perhaps there’s a third way – I would be grateful if any could share any ideas.
Yes, it was already discussed here: http://groups.google.com/group/boost-list/browse_thread/thread/d799ca8311850... I believe nothing changed since then.
Igor R wrote:
However on this glance this doesn’t seem possible non-intrusively. Perhaps I’ve missed something, perhaps there’s a third way – I would be grateful if any could share any ideas.
Yes, it was already discussed here: http://groups.google.com/group/boost-list/browse_thread/thread/d799ca8311850...
I believe nothing changed since then.
There's not a direct way to get at the internal representation of a ptime, which varies based on how the library is compiled (64 or 96 bits depending on settings -- the thread above isn't completely accurate on this point). If it's critically important, of course, you could modify the source directly to fit your particular setup and provide the internal representation for your app to serialize (add a to_int64 for example). As a general rule, however, it's unwise to store these values as integers since future versions of the library might, for example, expand the epoch range and hence these serialized values wouldn't be compatible -- that, and the aforementioned fact that the internal size isn't fixed are a couple of the reasons there isn't direct access. Jeff
participants (3)
-
Igor R -
Jeff Garland -
Pete Bartlett