Ian Lewis wrote:
In other words, the timezone in which it was entered needs to be stored to figure out what day it was entered? Otherwise, wouldn't the local timezone be enough to serve as metadata when converting to a date?
The local timezone changes over time, and this is the source of the problem. I moved from one country to another and suddenly my VAT returns went haywire because transactions on the 1st of the month were now suddenly on the last day of the previous month, and therefore in a different VAT period.
Others might live in NY and fly to LA on business for a few days, updating their timezone while there. They will face the same problem.
Base accounting cares about dates and not times because accounting wants to break accounts into periods. If the date is ambiguous, then the period into which that transaction falls is ambiguous, and this affects things like tax and VAT returns, which in turn leaves the end user facing tax penalties.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
