Re: [boost] local_time seems not monotonic

Subject: Re: [boost] local_time seems not monotonic
From: Antonio Mancina (antomicx_at_[hidden])
Date: 2014-07-31 04:37:50

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.

Antonio