*** Bug 150749 has been marked as a duplicate of this bug. ***

Raising Severity because of repeated reporting.

Issue still exists in 2.0.x/SVN.

*** Bug 420217 has been marked as a duplicate of this bug. ***

I share a gnucash file via SVN with someone who is one timezone away from me. We discovered this today when she opened the legdger and the date on numerous transactions were different from the ones I have in mine. They are off by one day, but that is really confusing because the file is exactly the same between us. She is using an older version (1.8.12) and I am at 2.0.5.

I dont think Gnucash should try and be smart about things like this, the dates entered should be the dates entered, not auto-corrected. Or at least have it as an option.

Is there any way around this? I tried to set my TZ to her locale before starting the application, but that didn't change it.

*** Bug 454943 has been marked as a duplicate of this bug. ***

I just traveled to the UK from the USA west coast, my transactions are all a skew... graphs are a mess, cash flow is a mess, the list goes on and on.

Further (before realizing), I downloaded my recent transactions from my bank, I fear they will need manual adjustment when I return to my home time zone.

This is a *VERY* serious bug... first reported in 2004? Wow.... surly some gnucash developer has time to look into this?

...using GnuCash 2.2.1

I'm flattered.  Why does gnucash not save the time/date as UTC internally?

Created attachment 115950 [details]
Test case for UTC-7

This is a file of 24 transactions, with a "posted" timestamp for each hour of the day. It can be used to observe or test this bug. This file was created in the UTC-7 time zone, but can easily be modified to be any other time zone.

Created attachment 115989 [details] [review]
Proposed patch (first try)

The algorithm behind this patch is explained here:

https://lists.gnucash.org/pipermail/gnucash-devel/2008-August/023694.html

Created attachment 116610 [details] [review]
Proposed patch (second try)

This is exactly the same as the first patch, except that warning messages are only generated for bug-affected timestamps.

My experiences are at http://thread.gmane.org/gmane.comp.gnome.apps.gnucash.devel/24443  The time stamp is comletely off-mark.

Re comment 13, @Rolf: Your question concerned the sql backend, not the file backend. That's a new discussion - you should move that to a new bug which deals with the SQL backend.

Re comment 12: I'd like to commit this patch. I think it is a reasonable compromise to fix the bug and yet doesn't loose too much of backward and forward compatiblity.

However, the discussion in August still had one issue open, https://lists.gnucash.org/pipermail/gnucash-devel/2008-August/023757.html , the recognition of book closing transactions. I didn't understand how Charles' patch would "screw up" if book closing transactions are present. As I understand it, we need to add a marker that indicates a transaction was automatically created. I've added such a marker in r17731, awaiting back-port.

Christian, thank you for your comment.

I understood http://thread.gmane.org/gmane.comp.gnome.apps.gnucash.devel/24443/focus=24445 that the data stored inside the XML file is already incorrect.  I'm not sure what the date/time-stamp should look like, so I cannot comment, but only refer to Derek here.

Re comment 14, Thanks Christian, I see that the marker for book closings has been added in r17731. I still don't have a development environment set up on my new Mac (in fact I'm just figuring out how to install 2.2.8) so I can't yet make adjustments to the patch to detect the marker. However this would still not help book closing transactions created in the past, since they wouldn't have the marker (I think this is what Rolf meant in comment 15).  I'm not sure what we can do about that.

I think gnucash saves two timestamps for each transaction, doesn't it.  One is the date for the receipt, the other when the transaction was keyed in.  While respecting timezone for the latter it makes absolutely *NO* sense for the former.  At least as long as gnucash assumes the transaction taking place at midnight which is what happens currently.  We don't enter an hour for tx date, why is gnucash trying to be smart about this when it doesn't really have the data accurate up to the hour???

The entered data is only accured up to the date, no need to mess with timezones.

(In reply to comment #17)
> respecting timezone for the latter it makes absolutely *NO* sense for the
> former.

"respecting timezone for the latter does make sense, that is not true for the former."

What should happen with this patch?  I remember there was a discussion on gnucash-devel a while ago.  This patch is marked "accepted-commit_now", but I don't remember the discussion coming to any real agreement or conclusion.

I'm not sure. If I recall correctly, the patch is perfectly fine for anyone who hasn't used the book closing feature. For those that have used that feature, or will, the patch isn't good enough. It doesn't check for the book closing indicator (which was added after the patch was written).

There is also the open question of what to do about book closings that took place before the indicator was added. There is no way to detect them automatically, so I guess the user would have to be involved. That sounds like it would involve a druid, which is a huge effort as far as I'm concerned.  Otherwise we'd have to make the conversion completely  optional (pop up a question if posting times other than 00:00 are found in the file), which this patch doesn't do either.

I would like to point out a possibility that may not have been considered in order to resolve this problem.  I am not familiar with the code but I have some understanding of timezone issues so my input may be useful (or possibly not).

In the xml file the date posted for a transaction is stored as a local time with a UTC timezone offset.  My timezone is UTC+0100 and if I enter a transaction for 20 July then the value in the xml file is '2009-07-20 00:00:00 +0100'.  This is the start of 20th July (local time) with the fact that the local time is 1 hour ahead of UTC.  In order to extract the date from this for display in the register it is merely necessary to interpret the date portion and ignore the rest.  At the moment, I think, it is converted to the current local timezone first (which is what can cause the date change).  It may therefore be that the problem can be fixed in this case merely by changing the interpretation of the data from the xml file.  There is no need to change the format of the data in the file itself.

When the data is stored to a database however the situation changes.  The date/time is stored in UTC with no indication of the timezone.  Data is therefore lost (compared to the xml file) and I can see no way to recover it.  I would therefore suggest that it may be highly desirable that this is sorted before the first full release of the version that supports the database is made available.

A possibility to avoid this is to store the posted date/time in local time rather than UTC.  In the xml file this is just a matter of losing the +0100.  In the database, normally entered transactions would have a time of 000000 (preceeded by the date) and special ones for book closing and so on can have 235959 or whatever is appropriate.  As this would always be interpreted as a local time (whatever the user's current timezone) the date would always be exactly what is stored in the xml file or db.

Apologies if the above is a load of rubbish due to my lack of knowledge of the inner workings, but I thought I should provide my thoughts just in case they are helpful in finding a solution for this problem which seems to be rather problematic.

I'd like to see some action with this patch.

@Charles: (In reply to comment #20)
> It doesn't check for the book closing
> indicator (which was added after the patch was written).

Could you add support for that? gnucash 2.2.8 (December 2008) and later have that indicator, so at some point in time we can assume enough users will have it in their file. 

> Otherwise we'd have to make the conversion completely  optional (pop up a
> question if posting times other than 00:00 are found in the file), which this
> patch doesn't do either.

Could you add support for that as well? We should at least be able to fix this issue for users who didn't use the book closing, or used it only with 2.2.8 and higher. We can leave the implementation of a druid for later.

Once this two additional points are added, I would like to commit this patch to have it in 2.4.0.

Re comment#21: Please go through the full discussion here https://lists.gnucash.org/pipermail/gnucash-devel/2008-August/023757.html ; what you are proposing ("use the date part and ignore the rest") is basically saying we have a date data type in contrast to a date-and-time data type, which was also discussed there.

@Charles: (In reply to comment #20)
> It doesn't check for the book closing
> indicator (which was added after the patch was written).

Could you add support for checking the book closing indicator? gnucash 2.2.8 (December 2008) and later have that indicator. Since then, the 2009 book closing for sure has used this, so in order to get some improvement here, I vote for assuming all transactions of interest have this fixed.

In http://svn.gnucash.org/trac/changeset/18925 I've added a date setter for the transaction's posted-date which uses a GDate and stores it as a GDate kvp value. This works transparently for older existing transactions.

We can change the display and setting in the register to use a GDate as well, and eventually this will solve this issue correctly and for all cases.

Starting with http://svn.gnucash.org/trac/changeset/19555 the entered date is also saved as a kvp GDate, so that we at least have the date which the user saw when he entered it.

Im seeing this in 2.3.15. Disappointing to see this is in the latest dev yet logged in 2004. A transaction entered is specific to that entry no matter where I am, if I change timezone I'm not really seeing the logic that Id want the transaction times to change. This especially causes problems where someone else in another location is making the entries. Hope this gets picked up soon :)

*** Bug 643743 has been marked as a duplicate of this bug. ***

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.

It occurred to me today while writing a date-sensitive test function that we could solve most of the date problems by using GDates for most everything (GDateTimes might be appropriate for price quotes) and storing the GDate Julian value instead of a timespec. (The GDate Julian value is the number of days since 1 Jan 1, computed as if the Gregorian calendar had been in use since then.)

Is there a workaround for this other than requiring every computer that will be using GnuCash in an organization to stay on the same timezone forever? BTW, this is a critical bug. This is an accounting program, it is literally worse than useless if you can't depend on the transaction data to be preserved and displayed as entered.  At least if it didn't work at all, you'd know to try something else, rather than entering months of data only to find that it has been manipulated into something that may or may not be correct.

(In reply to comment #30)
> Is there a workaround for this other than requiring every computer that will be
> using GnuCash in an organization to stay on the same timezone forever?

Yes, all you need is for all GnuCash processes in the organization to stay in the same timezone forever.  When I first discovered this problem, I wrote a little wrapper script that runs "TZ=:America/New_York /usr/bin/gnucash".  Now that I live in :America/Los_Angeles, I find it a little distracting that after 9 PM, the date defaults to tomorrow, but otherwise things are OK.

(In reply to comment #31)
> (In reply to comment #30)
> > Is there a workaround for this other than requiring every computer that will be
> > using GnuCash in an organization to stay on the same timezone forever?
> 
> Yes, all you need is for all GnuCash processes in the organization to stay in
> the same timezone forever.  When I first discovered this problem, I wrote a
> little wrapper script that runs "TZ=:America/New_York /usr/bin/gnucash".

How would that work for the Win32 version?  I don't believe you can specify the TZ for specific processes in Windows.  Is there a way to pass the TZ to gnucash as a startup parameter or manually enter it into a config file?

Searching for a solution to a problem I've recently encountered led me here to this Bugzilla entry.  So, with much gratitude & appreciation for the work the GnuCash developers have already done in making such a great product, I'd like to `vote` for this bug to be fixed in an upcoming release.

My problem is that I share a GnuCash file between two computers; one is a Fedora Linux machine whose timezone is EST (Eastern Standard Time -- 5 hours behind UTC) and the other is a Windows XP machine whose timezone is EST5EDT.  (I.e. it observes Eastern Daylight Time, so for most of the year it displays a time 4 hours behind UTC.)

The problem is that transactions during Daylight Saving Time entered on the Windows XP machine get stored like this:

  <trn:date-posted>
    <ts:date>2011-05-06 00:00:00 -0400</ts:date>

and thus when opened on the Fedora machine show a posted date 1 day prior since 2011-05-06 00:00:00 EDT is equal to 2011-05-05 23:00:00 EST.

It would be great if GnuCash was changed so that:

1.  The assumed time of the transaction was noon instead of midnight; this would `hide` the problem from users of computers in timezones of less than 12 hours difference.

or

2.  One could optionally enter a time and/or timezone in with a transaction's date.  See https://bugzilla.gnome.org/show_bug.cgi?id=89439

or

3. One could set a `always assume timezone` option in the GnuCash file's preferences.


Thanks for considering these suggestions.

This is a serious problem for me, since my computer automatically adjustes the TimeZone according to my current location (this is actually useful). I believe the solution proposed by Peter Selinger is simple and pretty, see comment 28. I wonder why there is no discussion here. In any case, I hope this will be fixed as soon as possible.

*** Bug 707854 has been marked as a duplicate of this bug. ***

There is a date-posted kvp slot that is a gdate, since 2010. 
https://github.com/Gnucash/gnucash/commit/59be2dc692513bdd71ecfe2de0fb2abaef069002
For a strange reason, I don't see it in all transactions, and I haven't identified a pattern: i.e. which transactions have it and which ones don't. 

But if it was present in all transactions, then one could just modify the function that reads date-posted as an attribute to the transaction, and use the kvp slot instead. 

I'm looking for a pattern, but if anyone else can pin down when it's written and when it's not, do add a comment here :)

Writing it is enabled in https://github.com/Gnucash/gnucash/commit/0871866c3882b99cadadd63c71b8a23220060a64. It will be called every time the transaction is entered manually, but won't be called for imports or SX.

It's also a bit of a hack and not really necessary. Date/times are stored as iso dates (e.g. 2014-07-03 08:03:20 Z), so we're totally free to replace the internal representation. Since date_posted is always just a date, we can just stop using timespecs (which I intend to do anyway as part of converting from gdate to boost::calendar) and treat date_posted as a date instead of a time.

(In reply to comment #37)
> Writing it is enabled in
> https://github.com/Gnucash/gnucash/commit/0871866c3882b99cadadd63c71b8a23220060a64.

Yes, that's r19555 mentioned in comment #25. 

No, unfortunately it's not "not really necessary" currently - there is one difference. The point of this extra field is that the date-and-time field is ambiguous with respect to what date the user entered during entering this transaction. It is ambiguous because depending on the time zone the user's computer was set during entering (or viewing) the date-and-time, it could be one date or the other. Only the GDate field solves this ambiguity by stating which date the user really entered.

> Since date_posted is always just a date, we can just
> stop using timespecs (which I intend to do anyway as part of converting from
> gdate to boost::calendar) and treat date_posted as a date instead of a time.

Yes, I'm all for this change. As stated by various people including myself all along the years: The presentation shows only a date and not a date-and-time, so the storage should also do a date alone. Unfortunately the conversion from date-and-time to date is ambiguous because the conversion depends on the time zone for which it is done. This is exactly this bugreport here. Switching from a date-and-time type to a pure date type will also solve this bug.

This bug us still occuring in version 2.6.11 built 2016-01-11 on Windows 7 and 8.

I just realised that about 7 weeks of work, 100's of transactions, are now invalid.  I was doing some catchup during some offtime in New Zealand.

Is there any way to fix the data file to at least another time-zone?  Setting the timezone to New Zealand on the PC is not an option.

I see the last patch is almost 8 years old, and did not resolve the bug.  Is there any fix being worked on and do we have an ETA for it?

The transactions aren't invalid, they're just off by a day. You can edit the date on all of them if it's actually important.

We've just been discussing this in the developer list. We've decided to change the posted date timestamp to 1100 UTC regardless of timezone for 2.6.14 (2.6.13 release is too close to be sure of getting that change done in time). The local adjustment from that will remain the same day everywhere except the middle of the Pacific. We'll include a scrub function that modifies old data. We'll also make the data-load code able to read date-only posted dates; writing those will be in 2.8.

First, thanks for the prompt reply. Im glad the product is still being supported as I like the application.

(In reply to John Ralls from comment #40)
> The transactions aren't invalid, they're just off by a day. 

Ok, invalid is a bit strong, but there are some dates that should be on the 1st day of them month that is now the last day if the previous month.  This skews any form of monthly reporting, so yeah the transaction is off by a day which makes the report invalid.  

>You can edit the date on all of them if it's actually important.

Is there a way to edit them all at once, or do I have to go to each one and increase the day manually?  There are literally 100's of them, so to edit each individually, will be a huge task.

> We've just been discussing this in the developer list. We've decided to
> change the posted date timestamp to 1100 UTC regardless of timezone for
> 2.6.14 (2.6.13 release is too close to be sure of getting that change done
> in time). The local adjustment from that will remain the same day everywhere
> except the middle of the Pacific. We'll include a scrub function that
> modifies old data. We'll also make the data-load code able to read date-only
> posted dates; writing those will be in 2.8.

Understood, and glad to hear.  What is the time-frame for 2.6.14?

Also, I noticed that this also affects scheduled transactions.  I created a few scheduled transactions while I was in New Zealand, scheduled for the 24th of the month.  They were created on the 23rd of the month for May and June.

There's no way to bulk-edit from the GUI, but you can try editing your data file. Figure out the timezone offset between your current TZ and New Zealand. Supposing that you're in the UK it would be 11 hours: British Summer Time is +1 and New Zealand Standard time is +12. All of the posted dates that you created in New Zealand will have a date-time that looks like 2016-0m-xx 13:00:00. You need to create an edit rule that changes that to 2016-0n-yy 00:00:00, where n and yy represent the day after m and xx.

If you're willing to change the timezone on the computer back to New Zealand long enough to open and re-save the file, it will be easier: In that case just search and replace +1200 to whatever is your offset and save. Change the timezone back and open it in GnuCash and everything should be OK.

Be sure to save the file as plain text, ideally in UTF-8. Make a backup first!

The GnuCash release schedule is http://wiki.gnucash.org/wiki/Release_Schedule.

Thanks for pointing out the scheduled transaction scheduled dates. Those should clearly get the same treatment.

I am so glad this bug will finally get fixed. Meanwhile, for what it is worth, since I travel a lot and this really used to mess up my accounts, I have used the following workaround for the last several years (this works in Linux): I defined an alias

alias gnucash="TZ=ADT+3 gnucash"

This way, the GnuCash process will always use my home timezone (which is ADT+3), regardless of what timezone the rest of my system is set to.

I've pushed phase 1, which is the change to 11:00 UTC for most places (it's adjusted in timezones -12, +13, and +14 so that it won't immediately jump a day on them), to maint. It will be in 2.6.14. It includes a scrub to move all of the old transactions' times. The scrub will use that GDate slot if it's available.

Still not the perfect fix of using a date only; that has to wait for 2.8.0.

(In reply to John Ralls from comment #42)
> If you're willing to change the timezone on the computer back to New Zealand
> long enough to open and re-save the file, it will be easier: In that case
> just search and replace +1200 to whatever is your offset and save. Change
> the timezone back and open it in GnuCash and everything should be OK.

I was in New Zealand again for a few weeks. Since I have come back I have not used GnuCash again, so the file is still at GMT+12. I had a look now, and saw a few things to watch out for.

Some of the transactions have the following tags:
  <trn:date-posted>
    <ts:date>2016-04-26 00:00:00 +1200</ts:date>
  </trn:date-posted>
  <trn:date-entered>
    <ts:date>2016-05-01 13:02:43 +1200</ts:date>
  </trn:date-entered>
  <trn:slots>
    <slot>
      <slot:key>date-posted</slot:key>
      <slot:value type="gdate">
        <gdate>2016-04-26</gdate>
      </slot:value>
    </slot>
  </trn:slots>

From the date entered I can see this was done in New Zealand, (and it has the +1200), so I can just change the +1200 to +0200 (Home is am at GMT+2)

However I also see these
  <trn:date-posted>
    <ts:date>2016-03-26 11:00:00 +1300</ts:date>
  </trn:date-posted>
  <trn:date-entered>
    <ts:date>2016-04-03 04:04:30 +1200</ts:date>
  </trn:date-entered>
  <trn:slots>
    <slot>
      <slot:key>date-posted</slot:key>
      <slot:value type="gdate">
        <gdate>2016-03-26</gdate>
      </slot:value>
    </slot>

and
  <trn:date-posted>
    <ts:date>2016-07-20 10:00:00 +1200</ts:date>
  </trn:date-posted>
  <trn:date-entered>
    <ts:date>2016-06-22 23:03:46 +1200</ts:date>
  </trn:date-entered>
  <trn:slots>
    <slot>
      <slot:key>date-posted</slot:key>
      <slot:value type="gdate">
        <gdate>2016-07-20</gdate>
      </slot:value>
    </slot>
  </trn:slots>


From the posted date, it looks like these was posted when I was still at home  (00:00:00 +0200) and then updated by Gnucash to (11:00:00 +1300) and (10:00:00 +1200) when I was in New Zealand.  The first was during daylight saving in New Zealand and the second normal time in New Zealand.

The gotcha here is that you cannot just replace (+1200) with (+0200).  The search must also include the time, so search for (00:00:00 +1200).  This may also be an edge condition to look out for in the scrub function.

I would like to point out another very simple solution for this issue. Set TIME value for date-posted to 12:00:00, instead of 00:00:00. 

Thus changing time zone for +/- 11 hours will not change the DATE of transaction.

Best Regards,

(In reply to Litnitskiy Alexander from comment #46)
> I would like to point out another very simple solution for this issue. Set
> TIME value for date-posted to 12:00:00, instead of 00:00:00. 
> 
> Thus changing time zone for +/- 11 hours will not change the DATE of
> transaction.
> 
> Best Regards,

See comment 44. 11:00 turned out to be a minute late as it still became 00:00 the following day in +13 (New Zealand Daylight Time). The code shifts more for +14 (Kiribati) and less of -12 (Wake Island).

GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=137017. Please continue processing the bug there and please update any external references or bookmarks.