RFC: Timestamps/timezones proposal

Charles Day cedayiv at gmail.com
Fri Jul 18 12:42:48 EDT 2008

On Fri, Jul 18, 2008 at 9:23 AM, Graham Leggett <minfrin at sharp.fm> wrote:

> Charles Day wrote:
>  No, splits don't have posting dates or times. The entire transaction uses
>> a single timestamp. That's how it works now. Under this proposal, that
>> timestamp would only be *displayed* differently in different registers, or
>> not, according to your preference.
> This is still very broken.
> If the accounts have different timezones, then the split in account A can
> fall on a different date to the split in account B, even though they have
> the same timestamp. User confusion results.
> You can try and kludge it as much as you like: A timestamp will never
> reliably represent a date no matter what hoops you jump through.
>  I disagree. If GnuCash uses timestamps, but a particular user such as
>> yourself wants to disable the effects of time of day and time zone
>> differences, then GnuCash could be set to use a single time zone for all
>> accounts. I imagine there being a global preference called something like "I
>> want to enter transaction times", which would be off by default, causing
>> GnuCash to completely ignore the time zone of your computer, So when you
>> moved your computer between time zones, it wouldn't affect your accounting.
> Under what circumstances would an end user ever choose the option "randomly
> change the dates on my transactions when I change the timezone on my
> machine"?

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.

> As I have said before, there are *severe penalties* for getting financial
> information incorrect. Tax authorities will *fine* you for submitting
> inaccurate information. This bug exposes gnucash users to non trivial risk
> during a tax audit.
> Any fix to this problem must not include scope for a programmer of gnucash
> to accidentally use the system timezone for date calculations and in so
> doing introduce subtle to find and dangerous bugs.

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.

> Using timestamps is begging for trouble.
> Regards,
> Graham
> --


More information about the gnucash-devel mailing list