You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently our reports allow very flexible from and to date configuration however it has been reported that often they include data from dates outside of the range. This often happens because of timezones and 00:00 being represented at 23:00 etc.
We should write a series of tests to ensure that all of our reports represent only the data for the period they have been selected for.
The text was updated successfully, but these errors were encountered:
For the most part, I think these bugs can be avoided by passing all dates that come from the client through new Date() before giving them to the database. This will parse them according to JS's timezone interpretation rather than MySQL's (which sets 23:00 to the previous day).
If that doesn't cut it, we should likely just go to shipping all dates back to server as strings without timestamps. That could be accomplished by decorating the $httpParamSerializer service.
jniles
pushed a commit
to jniles/bhima
that referenced
this issue
Feb 27, 2017
This commit fixes the account report's date handling so that it limits
to the correct dates. It is a critical bug fix for Vanga.
Caused by a variation on Third-Culture-Software#1274.
This commit fixes the account report's date handling so that it limits
to the correct dates. It is a critical bug fix for Vanga.
Caused by a variation on #1274.
Currently our reports allow very flexible from and to date configuration however it has been reported that often they include data from dates outside of the range. This often happens because of timezones and 00:00 being represented at 23:00 etc.
We should write a series of tests to ensure that all of our reports represent only the data for the period they have been selected for.
The text was updated successfully, but these errors were encountered: