After copying VT /dat to Raspberry Pi, Revenu shows on wrong day about viewtouch

[jcrafty]

I took another backup today. This time I didn't use a USB Fat32 drive but formatted it EXT4 in case files details were note being persevered and this mattered.

Last sales were done on Sunday 8 Aug. When I restore the /dat folder to the Raspberry Pi (from the Nuc) all transactions are shifted 5 days into the future. Sunday's totals show on Friday 13 Aug. This is consistent with all other observations. I confirmed both the Nuc and the Pi have the correct system date/time. Any ideas how to get the dates to show on the correct date on the Pi?

[NeroBurner]

Do you find any dates, that aren't shifted outside of the revenue/archive? Asking to check if we have a general "date is parsed different on arm64 and amd64" or if it is something else

[GeneMosher]

At 'End of Day', all of the day's transactions are saved in a file named with a six digit serial number. The number is incremented from the file name for the previous day and is written to the /usr/viewtouch/dat/archive directory. If no 'End of Day' is performed then the transactions to be saved span the entire period of days since the last 'End of Day' was performed. In this case the number of days is some number greater than several hundred. When designing the building of the sales history we considered making 'End of Day' automatic but decided against making 'End of Day' automatic. I have since given a lot of thought about the performance of the End of Day code and the writing of the file to be made without the explicit assent of the user. The code performed at end of day is automatic but End of Day requires +that there are no 'Open Checks' (i.e., incomplete transactions). If End of Day is to made automatic then the issue of how 'Open Checks' is to be handled. Currently, End of Day can be performed OPTIONALLY by allowing Open Checks to remain open ! This provision was written into the code so that restaurant which are open 24 hours each day can have End of Day without finalizing Guest Checks.

It must be noted that in the past year the code ViewTouch uses for time and date has been entirely refactored. ViewTouch currently uses Howard Hinnant's date and time library. It is entirely possible that this problem is the result of ViewTouch code which is no longer in use and that the new date and time library prevents this problem from happening in the current code base.

It may not be practical or even be possible either to figure out what causes this 'offset' problem or how to correct it. If there's any good news regarding this problem it is that no one else has reported it. I am inclined to suggest that a print or screenshot(s) of the significant facts from the historical data can be made, then delete the contents of /usr/viewtouch/dat/archive and begin anew to build the history of transactions in the archive directory. It is not unusual to simply settle for a solution to a problem which allows for a way forward but which doesn't involve understanding why the problem exists.

We really have no choice going forward other than to spend the resources we have on any of the other many things we can do to improve ViewTouch, especially for issues which affect all ViewTouch customers and users.