RFC: Timestamps/timezones proposal

[Charles Day]

On Fri, Jul 18, 2008 at 10:18 AM, Graham Leggett <minfrin at sharp.fm> 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