Re: [boost] local_time seems not monotonic

Subject: Re: [boost] local_time seems not monotonic
From: Eric Niebler (eniebler_at_[hidden])
Date: 2014-07-31 12:16:17

On 7/31/2014 1:37 AM, Antonio Mancina wrote:
> Hi Gaetano and all,
> 
> 
> Gaetano Mendola <mendola <at> gmail.com> writes:
>>
>> The following snippet seems to generate non monotonic local_date.
>>
>> I'm using boost 1.55 on linux.
>> [CUT]
>> Am I missing something ?
> 
> 
> some further investigation on this issue seemed to show that the problem is
> the following:
> 
> The
> 
> static time_type local_time(shared_ptr<time_zone_type> tz_ptr)
> 
> function, computes the local time by executing, in short sequence, these two
> instructions
> 
> utc_time_type utc_time = second_clock::universal_time();
> time_duration_type utc_offset = second_clock::local_time() - utc_time;
> 
> Both the local_time() and universal_time() calls get a time information
> 
>     static time_type local_time()
>     {
>       ::std::time_t t;
>       ::std::time(&t);
>       ::std::tm curr, *curr_ptr;
>       //curr_ptr = ::std::localtime(&t);
>       curr_ptr = c_time::localtime(&t, &curr);
>       return create_time(curr_ptr);
>     }
> 
>     static time_type universal_time()
>     {
> 
>       ::std::time_t t;
>       ::std::time(&t);
>       ::std::tm curr, *curr_ptr;
>       //curr_ptr = ::std::gmtime(&t);
>       curr_ptr = c_time::gmtime(&t, &curr);
>       return create_time(curr_ptr);
>     }
> 
> and finally invoke the create_time() function.
> 
>     static time_type create_time(::std::tm* current)
>     {
>       date_type d(static_cast<unsigned short>(current->tm_year + 1900),
>                   static_cast<unsigned short>(current->tm_mon + 1),
>                   static_cast<unsigned short>(current->tm_mday));
>       time_duration_type td(current->tm_hour,
>                             current->tm_min,
>                             current->tm_sec);
>       return time_type(d,td);
>     }
> 
> create_time() simply builds a time information with a sec granularity (ms
> are NOT considered).
> 
> So, let's assume that
> 
> universal_time() gets called at PM 1:00:00_989ms UTC
> local_time()     gets called at PM 3:00:01_002ms UTC+2 (so actually 13 ms
> later)
> 
> Then, create_time() truncates the milliseconds information and the
> utc_offset gets a +1 seconds offset with respect to the correct value.

Please file a bug in our tracker: https://svn.boost.org/trac/boost/. Thanks.

-- 
Eric Niebler
Boost.org
http://www.boost.org