Isaac-GC
commented
5 months ago The plan is to break it out in the future, but as you mentioned we should check the scope of the entirety of the issue. I included it in the function to ensure its scope is only applied to that section and children that use it.
For the scope of the issue, if you look at the db patch, it shows all of the models affected
After doing some testing in various timezones it looks like this (very ugly) patch successfully fixes the various timestamp inconsistency issues, which resulted in incorrect ledgers, profit/loss, etc
What was happening is that depending on one's timezone, the Date that was saved in the JournalEntry/Ledger would convert the Datetime to a timestamp of
00:00.000for the local timezone and then calculates the GMT timestamp based on the local timezone. This creates an instance where what is saved may not properly reflect what was entered and expected in the related invoices (or other items).Here are two test cases showing the issue of what was happening:
GMT +6.5)The time is converted to GMT which is 6.5 hours behind Myanmar at that point of time, resulting in saving the datetime as previous date (in this test case,
2022-12-31T17:30.000Z)GMT -8)In this case, when the timestamp for the local timezone is
00:00.000, GMT time will be 8 hours ahead (2023-01-01T08:00.000Z)