Derek Atkins wrote:
Yes, but how would you like it if we forced the issue and the way GnuCash did it was NOT the way you needed it done? Wouldn't you prefer to be able to set it up for your particular locale in the way YOU need it to be done?
I've worked in finance for a long time (first insurance, then investment banking) - a "date" is a universal concept across the world that is very different from a timestamp.
These kind of date problems are not unique to gnucash, banking software suffers from the same pain when timestamps are used instead of dates, particularly in the Java world where there has never been a clear distinction between "timestamp" and "date".
Absolutely! Which is why I think the flexibility is IMPORTANT, because what you need and what your neighbor needs are not necessarily the same. But if GnuCash is agnostic then we can let you set it up one way and them set it up differently and GnuCash just doesn't care! You both win. In this case, using timestamps lets this happen. Using day stamps does not.
Using timestamps caused my VAT returns to become bogus the moment I moved countries and changed the timezone on my machine. This is not flexibility, this is a severe design flaw.
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
