[Boost-users] [date_time][serialization] Fast persistence of boost::date_time::ptime

[Pete Bartlett]

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

 

 

[Igor R]

> 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/d799ca83118501e4/04b184b4c7af8c0b?show_docid=04b184b4c7af8c0b

I believe nothing changed since then.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users

[Jeff Garland]

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/d799ca83118501e4/04b184b4c7af8c0b?show_docid=04b184b4c7af8c0b
>
> 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