Boost C++ Libraries: Ticket #9584: date_time::difference produces incorrect values

Fri, 17 Jan 2014 10:18:46 GMT

FWIW, the obvious workaround is to return utc_dt.time() - local_dt.time(), but that doesn't make the difference() method any less broken.

anonymous — Fri, 17 Jan 2014 10:41:23 GMT

Sorry, my "expected output" was wrong. I'm going to assume that the sign is correct because the docs for ::difference() are unclear (is it subtracting this from other?).

Then, I expect to see -25200 and -28800 (because the first timestamp is in daylight savings time, while the latter is not).

The off-by-one error with difference() is pretty systematic, so maybe it's by design?

Also, I tried to use that function to compute the difference in seconds across 40 years, and it returned garbage, so something probably overflowed.

My current guess is that one should always prefer to subtract the results of calling the ::time() method instead of relying on ::difference().

Artyom Beilis — Mon, 20 Jan 2014 08:31:55 GMT

You incorrectly assume that for an object date_time, setting 6 parameters Y-M-D-H-M-S one afte another is the same as setting them all together.

Additionally, if you open a bug ticked you need to provide an information about the backend you are using. Also it is hard to check anything if you refer to a current time.

 date_time utc_dt{calendar(loc, "UTC")}

Is the time in current time.

So unless you provide some more valid information I can't help.

Mon, 20 Jan 2014 20:03:28 GMT

What does my *original* code print for you?

a) I'm clearly not intending to use the current time, since I'm overwriting all of YMDHMS with the values from a fixed timestamp. The current time should have no effect on this code.

b) How do you want me to be setting YMDHMS? The documentation does not suggest a better way to set all of YMDHMS together, and in any case, why is this incorrect? How can the results be different? If they can be, such an API is extremely unsafe to use (and the documentation again provides no warning).

c) I found no method that reveals the current back-end name. Can you suggest one? This is Ubuntu 13.10 with a full install of Boost, and ICU is installed also, so I assume that it's using ICU.

d) The off-by-one-second error I originally reported is not so good (it might be due to rounding errors in the way I construct local_dt above), and I'd encourage you to actually try my original code to see if you can reproduce it. However, this seems even worse:

#include <boost/locale.hpp>
#include <iostream>
int main(int argc, char **argv) {
  if (argc < 4) {
    return 1;
  }
  using namespace std;
  using namespace boost::locale;
  locale loc = generator{}("");
  auto cal = (strlen(argv[3]) == 0) ? calendar(loc) : calendar(loc, argv[3]);
  date_time a((double)atoi(argv[1]), cal);
  date_time b((double)atoi(argv[2]), cal);
  cout << a << " - " << b << " = " << a.difference(b, period::second()) << endl
    << b << " - " << a << " = " << b.difference(a, period::second()) << endl;
  return 0;
}

Neither of its outputs is even remotely correct. If the library cannot handle a 40-year difference, it should probably throw rather than make up numbers...

g++ -std=c++11 bug.cpp -o bug -lboost_locale; ./bug 0 1390247464 ''
0 - 1.39025e+09 = 0
1.39025e+09 - 0 = 536870912

maksqwe1@… — Mon, 23 Feb 2015 08:54:22 GMT

Fix:

github com/boostorg/locale/pull/6

bstbg.20.lesha@… — Tue, 24 Feb 2015 04:54:18 GMT

Thank you!

bstbg.20.lesha@… — Tue, 24 Feb 2015 04:56:23 GMT

Thank you!

status changed; resolution set

Artyom Beilis — Thu, 13 Jul 2017 14:53:34 GMT

status new → closed
resolution → fixed