[prev in list] [next in list] [prev in thread] [next in thread] 

List:       boost
Subject:    Re: [boost] =?utf-8?q?local=5Ftime_seems_not_monotonic?=
From:       Antonio Mancina <antomicx () gmail ! com>
Date:       2014-07-31 8:37:50
Message-ID: loom.20140731T103635-71 () post ! gmane ! org
[Download RAW message or body]

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


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[prev in list] [next in list] [prev in thread] [next in thread]