Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.7
    • Labels:
      None
    • Environment:

      Windows XP
      Reproduced both with the python API and the .Net API

      Description

      The timestamps for configuration and instrumentation messages are incorrect both with the python and the .Net api.
      According to the documentation "All timestamps are uint64 values representing nanoseconds since the epoch (January 1, 1970)." However, the dates resulting can be several years in the past or in the future.

      To reproduce with the python api :

      • in disp.py, line 178 add the following line :
        print gmtime (nsec / 1000000000)
      • start qpid-tool and list the queues => the full dates will be displayed
      1. qpid-1904.patch
        1 kB
        Kerry Bonin
      2. qpid-dates.png
        10 kB
        Julien Lavigne du Cadet

        Activity

        Hide
        Julien Lavigne du Cadet added a comment -

        See the screenshot for an example of an obviously wrong date

        Show
        Julien Lavigne du Cadet added a comment - See the screenshot for an example of an obviously wrong date
        Hide
        Julien Lavigne du Cadet added a comment -

        Please note that it only happens with brokers running on Windows. Timestamps are correct when the broker is running under linux.

        I also think that it's quite a significant issue and that it should be resolved asap !

        Show
        Julien Lavigne du Cadet added a comment - Please note that it only happens with brokers running on Windows. Timestamps are correct when the broker is running under linux. I also think that it's quite a significant issue and that it should be resolved asap !
        Hide
        Andrew Stitcher added a comment -

        I suspect this is an issue with the qmf code using the underlying qpid::sys:AbsTime class representation directly and assuming it is a since the 1970 epoch.

        This is not not the case - as documented in cpp/src/qpid/sys/Time.h the value is nanosecs since an unknown base. Accidentally it is probably since 1/1/970 on unix systems, but on Windows I'd bet the epoch is different.

        This class was never intended to represent calendar time and so there is no facility to convert it directly.

        I guess the quick fix is to shift the epoch base of the windows code when converting AbsTime to Duration since that is the only way to gain access to the internal nanosec from epoch value.

        A better way would be to introduce a calendar date to AbsTime constructor so that you can specify the epoch base when you convert to Duration (negative values of AbsTime are perfectly meaningful for this class).

        Show
        Andrew Stitcher added a comment - I suspect this is an issue with the qmf code using the underlying qpid::sys:AbsTime class representation directly and assuming it is a since the 1970 epoch. This is not not the case - as documented in cpp/src/qpid/sys/Time.h the value is nanosecs since an unknown base. Accidentally it is probably since 1/1/970 on unix systems, but on Windows I'd bet the epoch is different. This class was never intended to represent calendar time and so there is no facility to convert it directly. I guess the quick fix is to shift the epoch base of the windows code when converting AbsTime to Duration since that is the only way to gain access to the internal nanosec from epoch value. A better way would be to introduce a calendar date to AbsTime constructor so that you can specify the epoch base when you convert to Duration (negative values of AbsTime are perfectly meaningful for this class).
        Hide
        Andrew Stitcher added a comment -

        From inspection I suspect this code in cpp/src/qpid/sys/windows/Time.cpp:

        Duration::Duration(const AbsTime& time0) : nanosecs(0)

        { time_period p(ptime(min_date_time), time0.timepoint); nanosecs = p.length().total_nanoseconds(); }

        I suspect that ptime(min_date_time) is NOT the 1970 epoch.

        Show
        Andrew Stitcher added a comment - From inspection I suspect this code in cpp/src/qpid/sys/windows/Time.cpp: Duration::Duration(const AbsTime& time0) : nanosecs(0) { time_period p(ptime(min_date_time), time0.timepoint); nanosecs = p.length().total_nanoseconds(); } I suspect that ptime(min_date_time) is NOT the 1970 epoch.
        Hide
        Julien Lavigne du Cadet added a comment -

        Can someone comment on the status of this bug? Is it fixed for 0.6?

        Show
        Julien Lavigne du Cadet added a comment - Can someone comment on the status of this bug? Is it fixed for 0.6?
        Hide
        Steve Huston added a comment -

        It's still open; no patches have been proposed. No fix is in 0.6.

        Show
        Steve Huston added a comment - It's still open; no patches have been proposed. No fix is in 0.6.
        Hide
        Kerry Bonin added a comment -

        The underlying problem appears to be as described - boost::posix::ptime inherits its epoch from the underlying platform, causing a discrepancy across some platforms. This is primarily an issue for Windows.

        The applied patch adds a static variable to the Duration class equal to the qpid specified epoch in TimePrivate format, which is a boost::posix::ptime value, and initialized using the boost::Gregorian::date class. This is used in the Duration constructor taking an AbsTime value in place of ptime(min_date_time). The comments in Time.h are updated to reflect the epoch correction.

        Show
        Kerry Bonin added a comment - The underlying problem appears to be as described - boost::posix::ptime inherits its epoch from the underlying platform, causing a discrepancy across some platforms. This is primarily an issue for Windows. The applied patch adds a static variable to the Duration class equal to the qpid specified epoch in TimePrivate format, which is a boost::posix::ptime value, and initialized using the boost::Gregorian::date class. This is used in the Duration constructor taking an AbsTime value in place of ptime(min_date_time). The comments in Time.h are updated to reflect the epoch correction.
        Hide
        Andrew Stitcher added a comment -

        Since r931782 There has been an explicit constant AbsTime for the Epoch. Every place that used to just convert an AbsTime into a Duration - Duration(AbsTime::now()) (which was always an operation with dubious semantics) should now do - Duration(AbsTime::EPOCH, AbsTime::now()).

        And the Duration constructor taking an AbsTime should be removed.

        Show
        Andrew Stitcher added a comment - Since r931782 There has been an explicit constant AbsTime for the Epoch. Every place that used to just convert an AbsTime into a Duration - Duration(AbsTime::now()) (which was always an operation with dubious semantics) should now do - Duration(AbsTime::EPOCH, AbsTime::now()). And the Duration constructor taking an AbsTime should be removed.

          People

          • Assignee:
            Andrew Stitcher
            Reporter:
            Julien Lavigne du Cadet
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development