On Thu 28/01/10 13:20 , Jeff Garland wrote:

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:

...

I believe nothing changed since then. There's not a direct way to get at the internal representation of a

http://groups.google.com/group/boost-list/browse_thread/thread/d799ca831185 01e4/04b184b4c7af8c0b?show_docid=04b184b4c7af8c0b> 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!