Boost C++ Libraries: Ticket #4543: ptime: year 2038 problem

ookami1@… — Sat, 18 Sep 2010 17:35:31 GMT

as a side note:

I wonder whether date_time could (or should) be brought fully in line with ISO 8601. Not yet supported is

day-of-week numbering 1-7
proleptic usage back to year 1 B.C.

Roland Bock's observation adds to this list.

cheers

Wolf Lammen

pjohnmeyer@… — Wed, 07 Mar 2012 22:04:53 GMT

I am curious what the path forward is on this bug, which still exists in 1.48. I have implemented my own version of "from_time_t" that we use on our project that extends the useful life of the function significantly.

The most confusing part of this problem, in my mind, is that you can achieve valid and invalid times by performing essentially the same set of operations. See below:

  std::time_t theT = std::time_t(LONG_MAX) + std::time_t(100000);
  auto tm1 = boost::posix_time::from_time_t(theT);
  auto tm2 = boost::posix_time::from_time_t(LONG_MAX) + boost::posix_time::seconds(100000);
  auto tm3 = myproject::from_time_t(theT);

tm1 is 1901-Dec-15 00:32:31, because the from_time_t cast to long (which is 32-bits on my platform, MSVC) causes the positive value LONG_MAX + 100000 to be interpreted as a negative value.

tm2 and tm3 both evaluate, correctly, to 2038-Jan-20 07:00:47. tm2 at a glance does nothing mathematically different; it simply adds in the additional 100000 seconds after from_time_t is called.

Here is the implementation of myproject::from_time_t. Yes it has magic numbers that I calculated by working backwards from the inner workings of the posix_time code, and it doesn't address the full range of possible values of a 64-bit time_t. It does, however, extend the max value to 9,012,505,233,654 seconds since the epoch. The impacts this has elsewhere, however, I have not yet examined -- I know that, for example, converting extremely high values to a gregorian date will cause a bad year exception.

  boost::posix_time::ptime myproject::from_time_t(std::time_t time)
  {
    return boost::posix_time::ptime(
      static_cast<boost::posix_time::ptime::time_rep_type>(
        210866803200000000ll + (time * 1000000) )
  }

az_sw_dude — Sun, 01 Jul 2012 18:23:00 GMT

This is a real issue, however, it goes beyond the implementation of this method. The seconds type itself has a limited range and is subject to this overflow. So this needs to be addressed more generally in the library.

status changed; milestone deleted

az_sw_dude — Sun, 01 Jul 2012 18:23:18 GMT

status new → assigned
milestone Boost 1.44.0

Wed, 16 Sep 2015 13:56:33 GMT

I found that in time_resolution_traits the variable type being used is a boost::int32_t. I changed this to std::time_t and the problems went away. This did require rebuilding some things. I was able to simplify to_time_t and from_time_t down to:

  //! Function that converts a time_t into a ptime.
  inline
  ptime from_time_t(std::time_t t)
  {
    return ptime(gregorian::date(1970,1,1)) + seconds(t);
  }
  //! Function that converts a ptime into a time_t
  inline
  std::time_t to_time_t(const ptime& pt)
  {
    return (pt - ptime(gregorian::date(1970,1,1))).total_seconds();
  }

What I am uncertain of is the effect this has on any backwards compatibility or i/o conversions for streaming. Thoughts?

Sat, 14 Nov 2015 15:09:51 GMT

Here are the changes I made. They are not yet in boost 1.60 but I believe they should be considered:

root@dvm5:/usr/local/src# diff boost_1_60_0_b1/boost/date_time/time_resolution_traits.hpp boost_1_59_0/boost/date_time/time_resolution_traits.hpp
12c12
<
---
> #include <ctime>
71c71
<            typename var_type = boost::int32_t >
---
>            typename var_type = std::time_t >

root@dvm5:/usr/local/src# diff boost_1_60_0_b1/boost/date_time/posix_time/conversion.hpp boost_1_59_0/boost/date_time/posix_time/conversion.hpp
12a13
> #include <boost/cstdint.hpp>
24d24
<
29,30c29
<     ptime start(gregorian::date(1970,1,1));
<     return start + seconds(static_cast<long>(t));
---
>     return ptime(gregorian::date(1970,1,1)) + seconds(t);
35c34
<   std::time_t to_time_t(ptime pt)
---
>   std::time_t to_time_t(const ptime& pt)
37,38c36
<     time_duration dur = pt - ptime(gregorian::date(1970,1,1));
<     return std::time_t(dur.total_seconds());
---
>     return (pt - ptime(gregorian::date(1970,1,1))).total_seconds();

TMx — Tue, 15 Mar 2016 06:52:32 GMT

We were also stumbling across that issue, and I would consider it a serious one. Since this is open for 6 years now, I wonder when is it planned to fix it? Will it be part of 1.61?

Thanks, Thomas

anonymous — Tue, 21 Feb 2017 20:57:28 GMT

Hi,

Can any Boost date_time maintainer consider the above patch provided by Jim King. It also fixes the year 2038 issues I have when using to_time_t.

Cheers, Romain

jim.king@… — Tue, 21 Feb 2017 21:51:19 GMT

https://github.com/boostorg/date_time/pull/35

I just realized there's no unit test that covers the original issue or the fix. Hopefully whomever is pulling in the fix into their module can add that.

anonymous — Mon, 27 Mar 2017 22:30:23 GMT

#2818 is even older than this bug, but it's the same. Any chance to be fixed in this decade?

anonymous — Tue, 28 Mar 2017 16:22:15 GMT

This may need to be brought to the attention of someone who organizes the boost project as a whole. This issue is serious and hasn't even been assigned to a milestone for 7 years.

Edward Diener — Tue, 28 Mar 2017 21:03:12 GMT

I merged the PR into the 'develop' branch but it may not make it into Boost 1.64, which is in beta testing. The original date_time author has not been active in Boost for a while so others, including myself, are trying to pay attention to bug reports and PRs for date_time.

James E. King, III — Fri, 22 Dec 2017 22:03:49 GMT

For folks who have commented on this issue in the past, the fix in 1.66.0 caused a serialization problem as the output was not properly versioned (no changes were made to accomodate the older 32-bit values), see https://github.com/boostorg/date_time/issues/56 for details.

owner, status changed; milestone set

James E. King, III — Thu, 18 Jan 2018 14:09:06 GMT

owner changed from az_sw_dude to James E. King, III
status assigned → new
milestone → Boost 1.67.0

All known y2038 issues are resolved in 1.67.0 so I am marking it as the milestone. These are covered by a variety of other trac issues.

status changed; resolution set

James E. King, III — Sun, 28 Jan 2018 16:23:40 GMT

status new → closed
resolution → fixed

Fix merged to master; resolved.