Re: [Boost-users] [date_time][serialization] Fast persistence ofboost::date_time::ptime

Subject: Re: [Boost-users] [date_time][serialization] Fast persistence ofboost::date_time::ptime
From: pete_at_[hidden]
Date: 2010-01-28 10:10:18

On Thu 28/01/10 13:20 , Jeff Garland <azswdude_at_[hidden]> wrote:

> Igor R wrote:
> >> However on this glance this doesn&rsquo;t seem possible
> non-intrusively. Perhaps
> >> I&rsquo;ve missed something, perhaps there&rsquo;s a third way
> &ndash; 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/d799ca831185
> 01e4/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

Thank you both for your helpful replies (and for the helpful library!)

They are good reasons. The Boost.Serialization library has it versioning mechanisms so it would be possible for a more intrusive set of load/save functions to be future- and config-proof as well as being fast. However whilst that would suit me, it has its costs - I am sure many like the readability of the current archives and I am sure the maintainer likes that the serialization functions only need to use public members of the date_time classes!