2

I'm making changes to an existing multiplatform library. The library currently uses time_t and time(NULL) to store "timestamps" of important events, but the seconds-resolution is no longer enough. The library already uses Boost for different things, so I was looking at converting all the time_t timestamps into one of the Boost.Date_Time objects.

But I'm a bit confused between "Posix Time" and "Local Time". Is the only difference that Local Time also includes a timezone? It seems that a ptime object can be converted to a local_date_time object by providing a timezone to use.

Am I right in thinking I should use ptime for storing the timestamps, and let clients/callers decide themselves if they want to convert to local_date_time if they require it?

Stéphane
  • 19,459
  • 24
  • 95
  • 136

1 Answers1

4

Short answer:

Yes, boost ptime will be the closest equivalent to a time_t; both are a seconds since Epoch/beginning of recorded time kind of representation. And Boost ptime can be freely converted to a Boost local_date_time given a timezone.

The normal use will be to store the Universal timestamp and convert it into a locally meaningful time for display on demand. So,

An east coast server might record some event, at the local time 2012-02-12 17:05 EST, which translates into the prime/time_t internal representation of seconds since Epoch as 2012-02-13 00:05 UTC and put that into the database. Then the Paris client can convert to local_date_time/struct tm as 2012-02-13 01:05 CET and the San Francisco client to 2012-02-12 13:05 PST.

Longer answer: (Probably not relevant to your application which is already standardized on time_t)

But on some occasions, you might store the local date time directly if the geographic component has some meaning. You might imagine many event sources around the world and it might be interesting to know whether those events are day-time or night-time locally. You might recover that 1 of 2 ways. Either store a local date time/struct tm directly/or other datetime offset/timezone type that retains the originating timezone and local time, e.g. 14:00 PST (daytime) or 03:05 CET (nighttime).

Or store the event with some ref to the originating source so the timezone can be recovered. But given maintenance that may delete the source, or the lack of any straightforward join, it's often easier than trying to reverse engineer whatever geographic info might be saved back into a timezone.

Wil Simpson
  • 56
  • 2