I have recently travelled a lot to different time zones. I noticed that when I open my Gnucash accounts in a different time zone, the dates of all of my transactions are often shifted by one day. For example, suppose that I have entered the following transactions at home:

03/01/2011: pay rent

Then I travel one time zone west. When I open my accounts, I see:

02/28/2011: pay rent

A similar behavior also sometimes occurs around the time when daylight savings time starts or stops. 

It is clear what happened here. The transaction dates are internally treated not as calendar dates, but as absolute times in seconds. The date for this particular transaction was saved in the GnuCash file as:

  <trn:date-posted>
    <ts:date>2011-03-01 00:00:00 -0400</ts:date>
  </trn:date-posted>

When I opened the file is the western time zone, this was interpreted as 11pm on Feburary 28. When I save the (unmodified) accounts while in the western time zone, this actually gets saved like this:

  <trn:date-posted>
    <ts:date>2011-02-28 23:00:00 -0500</ts:date>
  </trn:date-posted>

Why do I consider this a bug? Because calendar dates actually have a meaning in banking. Banks will post a transaction on a specific business day, for example Monday. They do not typically post it for a specific time in seconds, nor do they do business in the middle of the night. They also do not do business on Sundays. Rent gets paid on the first of the month. Bills are due on a certain day. Interest is calculated based on daily closing balances. If my credit card company says such-and-such was paid on March 1, I may not actually know or care what timezone the credit card company is located in. 

In some bad cases, a shift of dates can mean that a transaction that happened on January 1, 2010 is excluded from a company's income statement for 2010, because it is erroneously considered to have happened on December 31, 2009. This can have tax consequences, especially if the transaction was not actually included in 2009 taxes either. 

All of this shows that the basic unit of time in banking is the *day*, not the second. This is consistent with GnuCash's user interface, which shows only dates and not times in the "Date" field for transactions. The internal data structures should reflect this.

Certainly using midnight (00:00:00) as the default time for transactions is an especially bad idea, since almost no financial transactions actually happen at midnight, and moving even by one timezone can mess up the presentation of the data.

A workaround might be posting transactions at noon (12:00:00) instead. This way, one would be free to move to a number of nearby timezones and get correct results (unless one lives near the international date line). 

This is still problematic, however, because the system will still break if one travels far enough. 

The *correct* fix, I think, would be to change the semantics of the <trn:date-posted> field (and the corresponding data structure in the Engine) to represent an actual calendar date, without the time-of-day and timezone information: 

  <trn:date-posted>
    <ts:calendar-date>2011-03-01</ts:calendar-date>
  </trn:date-posted>

I realize this change would not be backward compatible. A backward compatible workaround might be to store the data as before, but change its semantics:

  <trn:date-posted>
    <ts:date>2011-03-01 00:00:00 -0400</ts:date>
  </trn:date-posted>

would always mean "On March 1, 2011" in every time zone, and the time and timezone information should be effectively ignored. (It could be kept for informational purposes, in case somebody is really interested in recording transactions by the second, but should certainly never be *changed* by the software once entered). That means that the internal engine data structure would have to store the time as seconds since the epoch, together with the timezone in which the data was *entered* (not the timezone of the system on which it is displayed).

Please note that my comments only apply to the "posted" date. As for the "entered" date, it of course makes sense to record the exact minute and second when it was entered, as that information is actually known and meaningful.

I am prepared to have a go at a patch, but where there are possible engine data structures involved, I'd rather have this looked at by an expert. 

There is also the question of how to convert existing accounts to the new system. Essentially the old dates should be rounded to the correct calendar date, based on a best guess of what the timezone was when the transaction was entered (unfortunately this information is not technically stored anywhere; but the fact that transactions always seem to be entered at 00:00:00 in the current time zone means that one can recover the information - except in cases where two timezones differ by more than 24 hours (like +12:00 and -12:00). 

Note: I confirmed this behavior under SVN revision 20364 (current).