Краткий ответ:
Да, boost ptime будет ближайшим эквивалентом time_t; обе являются секундами с момента представления эпохи / начала записанного времени. И Boost ptime может быть свободно преобразован в Boost local_date_time с учетом часового пояса.
Обычно используется для сохранения универсальной временной метки и преобразования ее в локально значимое время для отображения по требованию. Итак,
Сервер восточного побережья может записать какое-то событие по местному времени. положить это в базу данных. Затем парижский клиент может преобразовать в local_date_time / struct tm как 2012-02-13 01:05 CET, а клиент Сан-Франциско в 2012-02-12 13:05 PST.
Более длинный ответ: (Возможно, не относится к вашему приложению, которое уже стандартизировано по time_t)
Но в некоторых случаях вы можете хранить локальное время даты непосредственно , если географический компонент имеет некоторое значение. Вы можете представить себе множество источников событий по всему миру, и было бы интересно узнать, являются ли эти события днем или ночью локально. Вы можете восстановить это 1 из 2 способов. Либо сохраняйте локальное время даты / структуру tm напрямую / либо другой тип смещения даты / времени / часовой пояс, который сохраняет исходный часовой пояс и местное время, например, 14:00 по тихоокеанскому времени (днем) или 03:05 по московскому времени (ночью).
Или сохраните событие с некоторой ссылкой на исходный источник, чтобы можно было восстановить часовой пояс. Но с учетом обслуживания, которое может удалить источник, или из-за отсутствия какого-либо простого объединения, зачастую проще, чем пытаться реконструировать любую географическую информацию, которая может быть сохранена обратно во временную зону.