Boost C++ Libraries: Ticket #2819: boost::posix_time::hours, minutes, and seconds assume sizeof(long) == sizeof(int)

pelee@… — Tue, 03 Mar 2009 22:38:48 GMT

Making this change also causes a 64-to-32 bit warning in xtime. The solution is to update a call to posix_time::seconds() to cast its argument to boost::int32_t instead of long.

    operator system_time() const
    {
        return boost::posix_time::from_time_t(0)+
			boost::posix_time::seconds(static_cast<boost::int32_t>(sec))+
#ifdef BOOST_DATE_TIME_HAS_NANOSECONDS
            boost::posix_time::nanoseconds(nsec);
#else
        boost::posix_time::microseconds((nsec+500)/1000);
#endif
    }

robert.stewart@… — Thu, 13 Aug 2009 14:03:36 GMT

These same warnings occur for GCC 4.3.2 on 64b Linux.

Just casting to a smaller type is suspect as the caller can supply a value in the range of the larger type that overflows the smaller. The cast is acceptable if the range is checked, but it may be better to try to bring greater consistency to the integer types being used.

Thu, 29 Jul 2010 17:32:02 GMT

I just ran afoul of this impedance mismatch yet again. The value fit long, but not int, the underlying type of time_duration::sec_type in this case. The truncation caused a large negative value to be treated as a sizable positive value silently creating a future rather than past time.

I think the proper solution is to change the classes to use the typedefs from the base class, giving the following:

  class hours : public time_duration
  {
  public:
    explicit hours(hour_type h) :
      time_duration(h,0,0)
    {}
  };
  class minutes : public time_duration
  {
  public:
    explicit minutes(min_type m) :
      time_duration(0,m,0)
    {}
  };
  class seconds : public time_duration
  {
  public:
    explicit seconds(sec_type s) :
      time_duration(0,0,s)
    {}
  };

Ensuring values fit within those types then becomes the caller's responsibility; DateTime won't silently truncate or otherwise alter them.

pankajuj@… — Wed, 21 Dec 2011 04:37:16 GMT

Has anyone found a good fix for this issue? It looks like using the library for a 64 bit linux or mac platforms is not safe. Will the future version of boost have the fix?

owner, version, milestone changed

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

owner changed from az_sw_dude to James E. King, III
version Boost Release Branch → Boost 1.37.0
milestone Boost 1.39.0 → Boost 1.67.0

Resolved as part of github issue 56:

https://github.com/boostorg/date_time/commit/de171954fe45e4d1338a641ebe70a84a181bd258#diff-c68588b074fe6450f9ed1dedc759621eR94

status changed; resolution set

James E. King, III — Sun, 28 Jan 2018 16:22:55 GMT

status new → closed
resolution → fixed

Fix merged to master; resolved.