RFC: Timestamps/timezones proposal

[Graham Leggett]

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
--
-------------- 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/20080718/ac166e45/attachment.bin