Aaron,

Time, not timezone. All transactions were timestamped at midnight local time to signify the day. If you changed timezone to the east the date changed. This proposal, implemented in 2.6.14, changes the *time*, not the *time zone*, to 11:00 UTC so that for most timezones the date would stay the same. 2.6.15 will change it to 10:59 UTC because in New Zealand Summer Time 11:00 UTC is midnight the next day. Oops.

As you say, the time resolution for accounting is days, not minutes. The original developers of GnuCash decided to store dates as timespecs (resolution in nanoseconds!) anyway, and we've been dealing with trying to work around that poor decision almost ever since.

I believe this is a solved problem (it's *really* common), but maybe I'm missing something. The normal way to handle this is to have all times stored in UTC, and all input and display is done in local time. For example:

I'm in eastern time (normally UTC-5:00). I enter a transaction for 2012-02-14 22:00, and it's stored in the database as 2012-02-15 03:00 (UTC assumed). When I open gnucash in eastern time, this transaction shows up at 2012-02-14 22:00 as expected. If I open it in Israel (UTC+2:00), it shows up as 2012-02-15 05:00. This is because if something happened at 2012-02-15 03:00 EST, it happened at 2012-02-15 05:00 IST (Israeli Standard Time). They're the same time.

Using the timezone of UTC+11:00 for input, storage, and display is misleading. It doesn't match up to any perception of real-world time. Continuing the analogy, say I (in EST) send an e-mail at 2012-02-14 22:00 to a colleague in IST, saying "Happy Valentine's day; I entered the transaction just now.". (Of course, the timestamp on his e-mail says 2012-02-15 05:00 IST.) This will be stored in the gnucash database as 2012-02-14 22:00 (with an assumption of timezone UTC+11:00). My friend later opens the books in IST and sees the transaction as being entered 2012-02-14 22:00. He thinks, "Wait, that doesn't look right; let me check the e-mail", and sees the discrepancy. The other way around is no better (if my Israeli colleague created the transaction, then I later view this transaction in EST).

I didn't vote for this solution. Banking and finance is in general handled in "days" not "minutes", but if we're going to do accounting in minutes (or microseconds or whatever), we should do it reasonably.

I would prefer a simple approach. Expose the time for optional entry defaulting to the current time. For the time zone issue, either store the time zone in the file and expose it in the GUI or simply explain in the documentation that moving a data file to a different time zone has no effect on the date and time in previously entered transactions. Given that the next version of GnuCash might be multiuser, raising the possibility of multiple transactions entered at the same time from different time zones, the former approach might be the best.

My bank posts the minute and second (Local time) when I use a computer to transfer funds between accounts, but I think that it is only to an aid to uniquely identify transactions if there happens to be similar ones in the same account. That, in itself, is a valid reason to keep the time in the transaction record, but I think that it might be better in GnuCash to also add the time zone of the user who made the entry to the transaction (including Daylight time when applicable). Then the date could be shown as local date to solve the date display issue.

When entering a txn, why not just default to the local (pc) date and time, and allow the user to edit it?

Some txns I'd like to be the current date/time, but others I'd like to change backwards either the date and/or the time.