After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 767824 - Some UTC timezones incorrectly recognized on Windows 7
Some UTC timezones incorrectly recognized on Windows 7
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: General
git-maint
Other Windows
: Normal normal
: ---
Assigned To: gnucash-general-maint
gnucash-general-maint
Depends on:
Blocks:
 
 
Reported: 2016-06-18 18:57 UTC by Guðmundur Viktorsson
Modified: 2018-06-29 23:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Two .gnucash test files and two .png screenshots of generated reports (73.71 KB, application/zip)
2016-06-18 18:57 UTC, Guðmundur Viktorsson
Details

Description Guðmundur Viktorsson 2016-06-18 18:57:54 UTC
Created attachment 330006 [details]
Two .gnucash test files and two .png screenshots of generated reports

I live in a timezone which is on UTC/GMT all-year without observing daylight savings (Iceland). We used to typically use either "Casablanca" or "Dublin, London" timezones and simply disable DST, but since we now have the option it feels more natural to set the computer to a UTC timezone which does not have DST at all.

Timezones "(UTC) Monrovia, Reykjavik" and "(UTC) Coordinated Universal Time" seem to be incorrectly interpreted/recognized by Gnucash on Windows 7 as having an offset of +0002. See attached sample .gnucash file created under "(UTC) Monrovia, Reykjavik" and a comparison .gnucash file created identically but under "(UTC) Casablanca" without DST.

This causes strange behavior when generating reports, as transactions appear incorrectly classified on the previous day, which causes all sorts of problems (especially with year-end reports and turn-of-the-month). See attached .png images which both have a single transaction on 16.06.2016 but reports (generated under the same timezone as their respective .gnucash files) which differ.

Suggested workaround until fixed: Set your computer to use timezone "(UTC) Casablanca" (and disable DST) BEFORE creating a .gnucash file (i.e.: do not use Gnucash with "(UTC) Monrovia, Reykjavik" or "(UTC) Coordinated Universal Time" timezones).

Note that changing the timezone and opening an existing .gnucash file saved under "(UTC) Monrovia, Reykjavik" or "(UTC) Coordinated Universal Time" timezones might shift some/all transactions to the previous day (and I imagine that is also something that the developers want to take in to account when fixing this bug, to avoid silently "breaking" existing .gnucash files).

I have the following idea for a manual fix/workaround for existing .gnucash files, but I would love to get feedback on whether this makes sense or not: Open a (non-compressed) .gnucash file created under "(UTC) Monrovia, Reykjavik" and replace all instances of +0002 with +0000. Then set computer to "(UTC) Casablanca" (and disable DST) and now you can open and use the .gnucash file safely with Gnucash.

Tested on Gnucash version 2.6.12-2016-06-07-git-c0086e1+ (but I believe I observed the same bug in releases 2.6.12 and 2.6.11, just didn't figure it out back then).
Operating system: Windows 7 Professional SP1 64-bit.
Happy to provide further details and/or testing if needed.
Comment 1 John Ralls 2016-06-19 01:37:03 UTC
The actual bug is in glib, which doesn't create a valid time zone if the offset is 0. I've got a fix for that which I'll get into the Windows bundle for the next release. It's actually quite a long-standing bug; I introduced it in December 2012 when fixing up southern-hemisphere summer-time handling.

If you have a file that has seen only the one timezone you can edit it to change the +0002 to +0000. However if you save the file having opened it with a different timezone set and then gone back you may see that the posted times, which should be 00:00:00 are somewhat different. That's because the actual offset seems to be a random value near 2 minutes. I found that after round-tripping to Casablanca I had a residual 17 second error in the posted time.

I'll look into a scrub function to ensure that posted times (the only ones that really exhibit a problem in this case) with offsets < 30 minutes are changed to 0 and any minutes and seconds in the posted time are also removed.
Comment 2 Guðmundur Viktorsson 2016-06-19 16:05:54 UTC
A minor update. I opened my actual accounting file with a text editor and noticed that there I had a time offset of +0007 rather than +0002, in case that matters. I also noticed that the file's first transactions which I had manually entered had a timestamp of:

<trn:date-posted>
    <ts:date>2016-05-31 00:00:51 +0007</ts:date>
</trn:date-posted>

but all other transactions, imported with the CSV wizard, had:

<trn:date-posted>
  <ts:date>2016-06-03 00:00:00 +0007</ts:date>
</trn:date-posted>

(with different dates of course, dependent on the CSV date field.)

I can't recall whether I modified the computer's timezone settings between runs or not (I thought I hadn't, but I'm not sure).

After replacing all instances of +0000 with +0007 and all instances of 00:00:51 with 00:00:00 I set the computer to "(UTC) Dublin,...,London" with DST disabled, and then added a single transaction and saved. All transaction dates were correctly displayed and the reports seem to be consistent with transaction dates. However, looking at the .gnucash file I notice that every transaction has been changed from:

<trn:date-posted>
  <ts:date>2016-05-31 00:00:00 +0000</ts:date>
</trn:date-posted>
<trn:date-entered>
  <ts:date>2016-06-11 17:44:34 +0000</ts:date>
</trn:date-entered>

to:

<trn:date-posted>
  <ts:date>2016-05-31 01:00:00 +0100</ts:date>
</trn:date-posted>
<trn:date-entered>
  <ts:date>2016-06-11 18:44:34 +0100</ts:date>
</trn:date-entered>

(of course with different dates and date-entered times, but you see the pattern.)

At this point I'm a bit hesitant to move forward in case this might cause me problems in the future (f.ex. when the UK goes off DST this fall). Am I OK to proceed using this file? Are there any Gnucash flags (or compiler options) which I can use to either manually feed in a timezone offset of +0000 or tell Gnucash to stop worrying about timezones and just stick with the dates entered and shown in the register? Might I be better off with starting from the ground up with a fresh .gnucash file and redoing everything?
Comment 3 John Ralls 2016-06-19 22:29:14 UTC
OK, a different random number. Not really surprising.

01:00:00 +0100 is OK, when the time zone switches back to +0000 it will change to 00:00)00 +0100. The problem is that if you now record a new transaction in that timezone it will be recorded as 00:00:00 +0100 and when summer time ends the timestamp will be changed to 23:00:00 +0000 the day before. This is the ancient GnuCash bug 137017. There isn't any way around this at present, unfortunately, and starting over with a new GnuCash file won't change anything.  

The good news here is that GnuCash 2.6.13 will have the timezone problem fixed so you can go back to using the Reykjavik timezone and then you won't have to worry about summer time, though everyone in UTC that does observe summer time will. I imagine that they've gotten used to it.
Comment 4 Guðmundur Viktorsson 2016-06-20 00:01:23 UTC
So 2.6.13 should handle the Reykjavik timezone correctly and generate reports that are consistent with the dates shown in the register? Do you have any idea when the fix will available in a Windows installer (f.ex. maint)?
Comment 5 John Ralls 2016-06-20 00:19:07 UTC
That change wasn't in GnuCash itself, so it didn't trip a nightly. However I'm working on a file-fixing function that will trip tuesday's nightly. I don't think I'll get it pushed in time for tomorrow's.
Comment 6 John Ralls 2016-06-21 20:32:55 UTC
This should have the timezone fix in it:
http://code.gnucash.org/builds/win32/maint/gnucash-2.6.12-2016-06-21-git-71297be+-setup.exe
Comment 7 Guðmundur Viktorsson 2016-06-21 22:47:03 UTC
I can confirm that this (that is gnucash-2.6.12-2016-06-21-git-71297be+-setup.exe) seems to do the trick.

I manually edited my exisiting .gnucash file (which was created in the Reykjavik timezone) so the offset of all <ts:date>'s were +0000 (rather than the previous +0007). I then opened the .gnucash file (while keeping the Reykjavik timezone setting) and the register displays correct dates for transactions and reports classify the transaction on the correct dates as well.

Thanks for everything, I really appreciate it.
Comment 8 John Ralls 2016-06-21 22:53:12 UTC
Thanks for exercising a timezone condition I hadn't considered.
Comment 9 Guðmundur Viktorsson 2016-07-04 15:43:53 UTC
This bug seems to have been reintroduced in release 2.6.13

I just upgraded from gnucash-2.6.12-2016-06-21-git-71297be+ to 2.6.13 and created some transactions. I then noticed that my reports were classifying transactions on an incorrect date and looking at the .gnucash file I see that the first save with version 2.6.13 had replaced all instaces of "00:00:00 +0000" with "00:02:12 +0002". I manually edited the .gnucashfile to revert the changes and then installed gnucash-2.6.12-2016-06-21-git-71297be+ and everything seems to be back to normal (although a quick look at the diff indicates some transactions have been reorganized within the .gnucash file, but that shouldn't matter). Computer was set to Reykjavik timezone throughout.

This might belong as a seperate bug report, but I'll throw this here anyway:

After first installing gnucash-2.6.12-2016-06-21-git-71297be+-setup.exe a week or two ago I always get an application crash when starting Gnucash. I first get a error dialog with the following text:

"Microsoft Visual C++ Runtime Library

The application has requested the Runtime to terminate it in an unusual way."

after clicking OK I get a "gspan-win32-helper.exe" has stopped working" dialog with the following diagnostic info:

"Problem signature:
  Problem Event Name:	APPCRASH
  Application Name:	gspawn-win32-helper.exe
  Application Version:	0.0.0.0
  Application Timestamp:	5765c968
  Fault Module Name:	libglib-2.0-0.dll
  Fault Module Version:	2.38.2.0
  Fault Module Timestamp:	5765c965
  Exception Code:	40000015
  Exception Offset:	000377bd
  OS Version:	6.1.7601.2.1.0.256.48
  Locale ID:	1039
  Additional Information 1:	b806
  Additional Information 2:	b8069d145ed00030ccf92eb3f50b4bc9
  Additional Information 3:	bed4
  Additional Information 4:	bed485791f2d8b1ed0bd0bcaa8e3151a"

after I click "Close the program" on the crash dialog Gnucash starts up and functions without any problem.

I had imagned this might be connected to some configuration issues with my (several year old) Windows 7 installation and therefore decided not to report it until I had done some more testing on my end, and because it didn't bother me that much.

After installing 2.6.13 Gnucash starts without any programs crashing, and since 2.6.13 reintroduced the timezone bug I decided to tack this crash information here. Let me know if you'd like me to file a seperate bug report.
Comment 10 John Ralls 2016-07-04 21:50:58 UTC
The regression is weird, but I got frustrated with the build server and did an end-around for the Windows release. Can you try 
http://code.gnucash.org/builds/win32/releases/gnucash-2.6.13-setup.exe
to see if it also has the regression?

I'll have to research the gspawn-win32-helper program, I've never noticed it before.
Comment 11 John Ralls 2016-07-04 22:31:57 UTC
Never mind, I tested it myself, it has the same problem.
Comment 12 John Ralls 2016-07-12 04:34:22 UTC
http://code.gnucash.org/builds/win32/maint/gnucash-2.6.13-2016-07-11-git-6ad8ff3+-setup.exe just for you.

The new version of glib-win32-helper leaves the cmd window with the development warning open which is annoying, I'll have to look into that. At least it doesn't crash.
Comment 13 Chris Good 2016-07-22 07:04:43 UTC
Hi John,

There seems to be a problem with dates of transactions imported by the OFX importer. They all seem to be the day before they should be in GnuCash.
E.g. In OFX file: 28 Jun 2016, in GnuCash: 27 Jun 2016.

The import seems to be wrong in both 2.6.12 and 2.6.13. They both do the same thing.

I'm in Sydney GM-10 as currently not daylight saving. GMT-11 when daylight saving is in effect.
I've only tested in Windows 10.
All the dates in my OFX file are yyyymmddhhmmss but hhmmss is always 000000.

2.6.13 :
  1) Imported transaction: .ofx: <DTPOSTED>20160628000000
     uncompressed .gnucash
       <trn:date-posted>
         <ts:date>2016-06-27 00:00:00 +1000</ts:date>
  2) Old 2.6.12  entered, not imported transaction : 25/5/2016 is correct
     <trn:date-posted>
       <ts:date>2016-05-25 00:00:00 +1000</ts:date>

2.6.12 :
  1) Imported in 2.6.12:
     <trn:date-posted>
       <ts:date>2016-06-27 00:00:00 +1000</ts:date>

  2) Not imported transaction : Liz Gilles 25/5/2016
     <trn:date-posted>
       <ts:date>2016-05-25 00:00:00 +1000</ts:date>

Please let me know if you need more info.
Regards, Chris Good
Comment 14 John Ralls 2016-07-22 13:54:42 UTC
It's pretty obvious what's happening, the OFX date/time is being taken as UTC and midnight UTC is 1400 the day before in +1000. Then the posted-date-normalization runs and it becomes midnight the day before.

Clearly not the same bug, so please open a new one.
Comment 15 Chris Good 2016-08-13 06:37:19 UTC
Re comment #13 (problem with ofx import dates):
 Raised https://bugzilla.gnome.org/show_bug.cgi?id=769124 on 23rd July 2016.
Comment 16 John Ralls 2018-06-29 23:49:40 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=767824. Please update any external references or bookmarks.