On Fri, Jul 18, 2008 at 10:18 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> 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. > That's not random. The user chose to use multi-time-zone features and forgot to honor the preferences they selected. This is user error. Only those users who chose to enable multi-time-zone features would even have an opportunity to make this mistake. However, if you want a warning to pop up in this type of situation, that could be done. GnuCash would just have to remember the time zone of the last register that edited the transaction date, and compare it to the current register's time zone. 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. > Under this proposal, the time zone of the OS would have no effect whatsoever on GnuCash. When creating a new account with multi-time-zone features turned on, the default time zone would be set by a preference. So if you set your preference to "UTC+02", your accounts will all be created with UTC+02 by default, no matter where you are in the world. > > 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. > The reason for my proposal was explore whether it was even *possible* to use timestamps to implement both a "date only" experience and support new features for users who want to enter times and, optionally, use multiple time zones. All I hear so far is risk of user confusion (only affecting users that enable multiple time zone support) and risk of bugs. So far I have not heard anything to suggest that this proposal would make it impossible to provide users with a "date only" look and feel. Sure, bugs can happen either way. Your point with keeping it simple is a point taken, and the cost for keeping it simple is feature loss. So a risk vs. features tradeoff is there to be weighed. When figuring risk, just keep in mind that we're not starting from scratch; implementing "date only" is a major change because GnuCash is already built around timestamps. If someone could show that it was impossible to provide users with a "date only" look and feel while using timestamps internally, then that would help convince those in favor of timestamps to change their minds. > Regards, > Graham > -- > -Charles _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
