Charles Day wrote:
Tell me how this proposal would cause "random" date changes. Only the *display* of the timestamp changes, and only according to settings that you pick yourself.
Try this:Enter a transaction dated 1 March 2008 in an account with timezone UTC+02, with its split in a second account with a timezone of UTC.
Later, the user notices that in the second account, the transaction appears on 29 Feb 2008, goes "that's odd", and "corrects" the date to say 1 March 2008.
Without the user knowing, the transaction on 1 March is now actually on 2 March 2008.
Try this:Create a new account. The account is created with the local timezone as a sensible default. User thinks nothing of it and creates an account in timezone UTC+02.
Fast forward some time, change your timezone in the mean time. Create a new account. The account is created with the local timezone as a sensible default. User thinks nothing of it and creates an account in timezone UTC.
User encounters the first problem above and goes huh? Wastes lots of time, posts it as a bug, and then someone tells the user "oh it's supposed to work like that".
User ditches gnucash.
You ask the impossible. Using a date alone doesn't guarantee freedom from date-related bugs either. Considering the present state, switching to a date alone would actually be a larger coding effort, and therefore probably more bug prone.
You misunderstand the risk being faced.If a timestamp is used, it means that every single piece of time related code, must correctly respect the account timezone, at all times moving forward during development.
As soon as *one* developer at *any* time in the future makes *one* mistake with regards to the timezone, the bug is back.
The core premise behind defensive coding is choosing coding strategies that make it very difficult to make mistakes.
It is difficult to get a date wrong, because "1 March 2008" is always and without exception equal to "1 March 2008". "2 March 2008" is always and without exception exactly one day after "1 March 2008".
If you want to make life difficult for yourself and for end users, stick with the timestamps.
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
