"Charles Day" <[EMAIL PROTECTED]> writes:
> I'm afraid I don't follow your logic here. Could you explain why
> you say this? We already store a time now and we don't have a
> preference (6). Had GnuCash kept a stable timezone always then
> nobody would have every noticed there was a problem (except bug #89439)
> and this discussion would be a VERY different animal.
>
> What I mean is that if users were able to do time entry, and we stored the
> time but not a "user-entered" flag, then we wouldn't be able to tell which
> times were user-entered. So when you changed preference (6) it could only
> apply to new transactions.
I think changing the time in preference #6 should only affect new
transactions regardless! Preference #6 should never, IMHO, make
changes to already existing transactions.
So here's what I'm thinking:
1) Timestamps are always stored in UTC. But we do a conversion on entry
where we take the /local/ date and make a UTC timestamp out of it.
So if it's 2008-07-23 in localtime, we create a UTC timestamp of
2008-07-23 12:00:00 (even if we're in a locale where it's NOT the
same date in UTC). E.g., if we're in GMT+2 and it's 0100 then in
GMT it's still a day earlier, but we should use the local "today"
date when constructing the timestamp.
2) Dates (and times) are always displayed in UTC. So when we see a
timestamp of 2008-07-23 12:00:00 (UTC) we display it as 2008-07-23
(even if we're in GMT+14 or some other timezone that would put that
timestamp into a different date bracket).
3) Timestamp defaults to 1200 (UTC). Eventually we could add a preference
to allow users to change the default timestamp, but that setting would
only affect new transactions.
4) Eventually we could add a ToD setting, to let the user choose the
time of day of a transaction. This ToD is always stored and
displayed as UTC. By making the default 1200 it makes it really easy
to move transactions in front of or behind others without having
to adjust anything.
5) We need a procedure to determine that a data file is using old
timestamps and ask the user if they want to update their datafile.
Note that this does NOT change the format of the data file. We
just change the semantics.
Also note that the process in #5 would create a semantically
backwards-incompatible change to the data file... But I think
this is fine.
Finally, pretty much ALL of this work is in the UI.
Comments?
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
