time_t

[Graham Leggett]

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
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3287 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20080716/b219c521/attachment.bin