Charles Day wrote in the description of his patch at https://lists.gnucash.org/pipermail/gnucash-devel/2008-August/023694.html:

3. When reading a file, if the "HH:MM:SS" part is NOT equal to "00:00:00"
then the transaction is bug affected and must be reviewed to determine the
date the user originally entered in the register.
4. Once the date originally entered in the register has been determined,
GnuCash converts that date into a timestamp by imposing a default time of
day of midnight and using the LOCAL time zone.

I think this is a bad idea. It is based on repeated conversions between the following data types:

* the date data type (e.g. Julian date)
* the date-and-time data type (e.g. seconds since Epoch. Really this doesn't record "date" at all, just "time")

If I understand Charles's patch description correctly, his method is to use a date-and-time data type for in-file storage, convert it to a date data type upon reading the file, then converting this immediately back to a date-and-time data type for internal usage (not necessarily the same as originally in the file!). Finally, this adjusted date-and-time is written back to the file on saving. This is problematic in several situations:

* since the in-memory data structure is date-and-time, the display will be incorrect if the time zone changes after the file has already been loaded (e.g., when daylight savings time starts, or if one travels while GnuCashing. Given that I almost never quit GnuCash, I can sometimes have it open for weeks at a time). 

* The adjustment in each direction is lossy. When converting a date-and-time to a date, one has to guess the timezone, and if the time zone changes by more than 12 hours, or across the date line, it is impossible to guess. Similarly, the conversion from date to date-and-time relies on the local time zone, which information is later lost. 

* Since the algorithm continues to adjust the data each time the file is loaded, any errors that happen will accumulate over time. The data originally entered is lost. This is in contrast with a conversion to a new data type, which would only happen once. 

I don't really understand the problem with price sources that Charles described, nor how the described method is supposed to fix it. By converting all times to midnight on reading, the time-of-day information is in any case destroyed, so GnuCash effectively has to do price lookups based on the calendar date. Finding a "nearest in time" price source with less than day granularity is out of the question if the actual time of day of the transaction is not known in the first place. So at best one can look up a daily price source (e.g. daily average, mid-day, closing, or some other fixed time of day). 

Further, the price lookup should be independent of the local timezone of the up-looker. If I generate a report while travelling, I expect the report to be identical to what I would have gotten at home. If a user in Australia doesn't want to use London daily prices, then there should be a separate preference for that, such as "use Australian prices", or "use a price source for noon Australian time", or "use a price source for 1am GMT + 1 day", or "my company's home timezone is X". It should not be just guessed based on the user's current local time zone. 

If neither file backward compatibility nor future extensibility were an issue, the most sensible solution would be simply to use a "date" data type rather than "date and time" for the date-posted field.

For both backward compatibility and future extensibility, it might be desirable to retain the ability to store an exact date-and-time for a transaction, in those cases where a user might want to account for second-by-second transactions (such as live trading). However, such data should be stored *in addition to*, and not instead of, a calendar date. For example, a user in Canada might record a certain transaction as having occurred on 2011-03-02 at time 2011-03-03 03:48:00 +0000. On the other hand, a user in Australia might record the same transaction as having occurred on 2011-03-03 at time 2011-03-03 03:48:00 +0000. This is not a contradiction, as the calendar date is a nominal date, and is not a function of the current absolute time.

I therefore propose the following solution. Newer versions of GnuCash will store the posted date as follows (or similar):

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

Newer versions of GnuCash will treat the ts:date field as a comment, i.e., it is read and stored and later written (unmodified), but may not even be parsed (except perhaps to check syntactic correctness), and is definitely not used for anything. The ts:calendar-date field is used for all purposes as the posted date. When a new transaction is created, then the ts:calendar-date field is set as input by the user, and a corresponding ts:date field is created in the same way as current GnuCash versions, i.e., 00:00:00 in the current timezone. This is only for backward compatibility. 

When a newer version of GnuCash encounters a file written by an older version of GnuCash, it will note the absence of the ts:calendar-date field, and will fill in this field by a best-guess method from the ts:date field. However, this only happens once; on subsequent writes and reads, the actual ts:calendar-date is used. This way, there will be no cumulative errors from subsequent guesses; if an error happens once, the user only needs to correct it once. Also, since the ts:date field was not modified, none of the original data was lost.

When an older version of GnuCash encounters a file written by the newer version, it will not recognize the ts:calendar-date field, and will therefore ignore it (I just checked and the field will indeed be ignored silently). It will use the ts:date field (and possibly display incorrect dates) as has always been the case. On saving, it will save only the ts:date field. If that file is later read by a newer GnuCash version, then the above guesswork will have to be repeated. However, this does not lead to cumulative errors, only (in the worst case) to an earlier error being repeated. Since the ts:date field still has its original value, the current guess will be no worse than the last one. There is no way around this if a user keeps switching between older and newer GnuCash versions. In no event will the behavior be worse than the current default behavior.  

Also note that the current time zone is not used for anything, except possibly as an input to the best-guess method for users that are very close to the date line or something. 

Are there any theoretical or practical issues with this approach? 

Instead of my proposed ts:calendar-date field, one can of course also use the 

    <slot>
      <slot:key>date-posted</slot:key>
      <slot:value type="gdate">
        <gdate>2011-04-02</gdate>
      </slot:value>
    </slot>

field that Christian has already added. That would have the added effect (presumably) that older GnuCash versions, while still ignoring the contents of the field, would nevertheless not erase it and would write it (unaltered) back to the file. That can be a bad thing if the user actually changes the date in the older GnuCash. If the file is later opened with newer GnuCash, the old unmodified date would still be used. On balance, that is probably a bad thing.

In any case, as a long-term file format, a dedicated ts:calendar-date field would perhaps make more sense than a key-value pair, because this is an integral (and mandatory) part of the transaction data, not some optional key-value type annotation.

I'd be happy to try a patch if people agree that there are no major problems with the approach.