I suspect that it's a plot by the date_time author to keep people from using time_t ;-)

Seriously though, while your function will work for some times, there are issues:

1) ptime can represent dates prior to 1970-1-1 and after 2038 (or wherever the upper bound of time_t is). Probably need an exception for these cases on the conversion. 2) ptime can represent times with less than 1 second resolution. Maybe the function should round instead of truncating in case the time is 2006-May-04 00:00:00.999999?

So if you're sure your application doesn't care about any of these issues than the function above should be fine.

Jeff

Thanks for the super quick reply. That's the fastest response I've gotten from this list! :) My application is dealing with retrieving TCP/IP packets stored on disk, which are in time_t. But I use boost to convert a user readable date into packet time. In this particular case, the truncating is okay. I removed the date vetting code for clarity. Thanks, Scott