44

Is there some "standard" way or the best I can do is to compute it directly by subtracting from gregorian::date(1970,1,1)?

Yakov Galka
  • 70,775
  • 16
  • 139
  • 220
  • 4
    Just a thought; I'm using boost::posix_time::from_time_t(0) instead of explicit time in Gregorian calendar, to get a reference-point that will automatically adjust to the epoch of the system compiled for. – Rawler Apr 18 '12 at 09:22
  • @Rawler, that's likely much better -- I've found that the actual epoch is apparently 2000ns prior to what's represented by `gregorian::date(1970,1,1)`. – Brian Cain Oct 25 '12 at 19:07
  • 1
    @BrianCain Where did you come up with 2000ns before the infamous epoch timestamp? As far as I remember and have read, I've always heard that epoch is 1970-01-01 00:00:00.0 UTC. – Stéphane Sep 17 '14 at 00:07

5 Answers5

37

Since @icecrime's method converts twice (ptime uses linear representation internally), I've decided to use direct computation instead. Here it is:

time_t to_time_t(boost::posix_time::ptime t)
{
    using namespace boost::posix_time;
    ptime epoch(boost::gregorian::date(1970,1,1));
    time_duration::sec_type x = (t - epoch).total_seconds();

    // ... check overflow here ...

    return time_t(x);
}

EDIT: Thanks @jaaw for bringing this to my attention. Since boost 1.58 this function is included in date_time/posix_time/conversion.hpp, std::time_t to_time_t(ptime pt).

Yakov Galka
  • 70,775
  • 16
  • 139
  • 220
  • 16
    such a pity that they've not added this as a direct function call in the library... I wonder what the reasons were... – Nim Dec 16 '10 at 22:49
  • 2
    could make ptime epoch static versus computing every call. – Gabe Rainbow Jun 16 '15 at 17:42
  • 3
    use std::time_t posix_time::to_time_t(posix_time::ptime pt) in conversion.hpp – jaaw Dec 15 '15 at 01:43
  • @jaaw: Thanks, it was added just recently. – Yakov Galka Dec 15 '15 at 13:19
  • Note that, as [@kgriffs says](http://stackoverflow.com/a/6849810/25507), `total_seconds()` uses 32 bits (at least on my 64-bit Ubuntu 14.04 system), so it overflows after 2038. Boost's own `to_time_t` uses this same implementation, so it also has this same limitation. – Josh Kelley May 06 '16 at 14:55
  • 2
    Keep in mind that a `ptime` can also have several special values (`not_a_date_time`, `pos_infin`, and `neg_infin`). Adding `assert(!t.is_special());` may be a good idea. (Boost's own `to_time_t` doesn't check for `is_special` either.) – Josh Kelley May 06 '16 at 14:57
16

time_t is the type used to hold time in seconds (typically epoch time). I'm guessing you are after epoch time, if so I'm not aware of any way in boost of actually getting epoch time directly, aside from the subtraction you have already. Once you have a time_duration (result of the subtraction), you can call total_seconds() on the duration and store that in time_t.

btw. if you are after epoch time, you could simple use gettimeofday() and save yourself some headache!

Nim
  • 33,299
  • 2
  • 62
  • 101
15

Here's a variation of @ybungalobill's method that will get you past 2038, just in case. :)

int64_t rax::ToPosix64(const boost::posix_time::ptime& pt)
{
  using namespace boost::posix_time;
  static ptime epoch(boost::gregorian::date(1970, 1, 1));
  time_duration diff(pt - epoch);
  return (diff.ticks() / diff.ticks_per_second());
}
kgriffs
  • 4,080
  • 5
  • 37
  • 42
  • 1
    Yes, but when you are writing a cross-platform app, you have to support 32-bit as well. – kgriffs Jul 29 '11 at 14:41
  • 2
    @ybungalobill: The problem isn't so much `time_t` but `time_duration::sec_type` which is 32-bit (at least on my machine). – Andreas Magnusson Nov 19 '12 at 11:55
  • 1
    Keep in mind that a `ptime` can also have several special values (`not_a_date_time`, `pos_infin`, and `neg_infin`). Adding `assert(!pt.is_special());` may be a good idea. – Josh Kelley May 06 '16 at 14:56
5

I believe the best you can do is using to_tm to get a tm and mktime to convert the tm to a time_t.

icecrime
  • 74,451
  • 13
  • 99
  • 111
  • 3
    But I believe mktime has implicit time zone adjustment (it shows number of seconds from epoch in local time)' – gerrytan Jan 17 '13 at 01:03
2

These 2 lines should do it.

tm td_tm = to_tm(pt);
time_t tt = mktime(&td_tm);
Shawn Chin
  • 84,080
  • 19
  • 162
  • 191
Ramesh
  • 21
  • 1
  • 5
    The thing to be careful with this and icecrime's solution above is posix mktime's input contract. mktime takes a struct "expressed as local time, to calendar time representation" and converts it for you. However, boost p_time does not do any TZ conversion for you when filling out the tm struct. So if you're looking for an absolute epoch time as # of seconds since UTC Jan 1, 1970 midnight and your machine's local TZ is not GMT, this call isn't going to get you what you want. Subtracting an explicitly constructed epoch and taking the second difference is clear, obvious and tz-safe. – timmyl Oct 08 '12 at 12:28