Re: [Boost-bugs] [Boost C++ Libraries] #4533: timespec translation fails for times before 1970

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #4533: timespec translation fails for times before 1970
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2011-12-09 13:03:44

#4533: timespec translation fails for times before 1970
----------------------------------------------+-----------------------------
  Reporter:  Philipp Huber <phu@…>            |       Owner:  viboes       
      Type:  Bugs                             |      Status:  assigned     
 Milestone:  To Be Determined                 |   Component:  thread       
   Version:  Boost 1.43.0                     |    Severity:  Problem      
Resolution:                                   |    Keywords:  absolute time
----------------------------------------------+-----------------------------

Comment (by phu@…):

 Hi Vicente

 Thanks for taking up the bug. Right you are, better late than never.
 I stripped the answer a bit to get to the point:

 Replying to [comment:7 viboes]:
 > Replying to [comment:6 phu@…]:
 >
 > Thanks for the explanation. IIUC,and if you where using directly the
 underlying platform you will need to make sure that the time given satisfy
 the interface constraints ...
 Well, we have a correct linux system time. Even if it shows the year 1919,
 I think it perfectly satisfy the interface constraints. Well, I might be a
 bit naive on that point.
 > ... and when you did a difference you will ensure that the seconds and
 nanoseconds will be positive, isn't it?
 We subtract two ptime values. I expect the value to be usable for further
 operations. I would not check every subtraction for its correct value
 (whether its components are positive or not), that is what I expect of the
 operation to do.
 >
 > I think that you will do the same when using Boost.Chrono. The best I
 can do is to add an assertion so that the modification doesn't add code on
 release mode.
 Sorry, but I might be misunderstanding this point. If we end up with an
 assertion instead of a working program flow, I'm not exactly happy with
 the solution. Then I prefer you do nothing at all and we continue the way
 we did so far.

 > Let me know what do you think of this resolution?
 >
 > Best,
 > Vicente

 Thanks for looking into it anyway :-)
 Cheers
 Philipp

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/4533#comment:8>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.