Fix integration tests for round-off errors

[jmcameron]

In some cases on my dev environment, the test 'GET /stock/rumer (test/integration/stock/rumer.js)' was changing the startDate from '2022-01-01' to '2021-12-31'. I believe this due to the following sequence of commands in the test (and related files):

• get('/stock/rumer') with params.startDate = 2022-01-01
• The startDate is massaged in server/controllers/stock/functions/rumer.function.js : getData
  • params.start_date = moment(new Date(params.start_date)).format('YYYY-MM-DD');
  • This last line changes start_date as shown above.

Not sure why this happening. Is it related to the time zone or time of day?

However, the hack in the test file forces the moment to reconstruct the start_date string correctly.

[jniles]

@jmcameron , I don't think this is the root of the issue. The problem comes from two places:

(1) We translate all relative dates on the client to timestamps (for example, the bhDateInterval component makes "today" into two timestamps that correspond to the timezone the user is in, rather than the timezone the server is in).

And, what is happening here,

(2) The default database has very specific transaction timestamps in the test data. This means that the number of transactions made today on your system in California is not the same as the number of transactions made today on my system in Congo.

So, rather than hacking the tests to try and set a different search query that works universally, the fix is likely going to be setting both the test database timestamps to a given time zone (e.g. UTC) and also setting the test runner to the same timezone (e.g. UTC) so that my tests in Congo are running in the same reference frame as yours in California. I am not sure how easy or hard it would be to do so.

Note as well that this will likely break a fair number of tests, since we were not super strict about timezones when the authors were writing their tests.

[jmcameron]

Thanks to feedback from @jniles , I'll close this PR and work towards running all regression tests in UTC to avoid timezone problems.