RFC: Timestamps/timezones proposal

[Charles Day]

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
> --
>

-Charles