Created attachment 373145 [details] Screen shot and transactions I have three transactions which were posted on 2017-12-31 but which show in the register for the account they are all in as posted on 2018-12-31 (off by one year). Changing the date shows the correct date until the change is accepted, then it reverts to the wrong date. I've attached a ZIP file containing the transactions in question and a screen shot of the register display. Viewing the same transactions from the other accounts they have splits in shows the wrong date too. While checking this I discovered other transactions posted on 2015-12-31 which show in the register as posted on 2016-12-31. The register sorts the transactions according to their actual posted date, not the incorrect date displayed. I am running a MacOS Quartz build from the current maint branch.
Built how, using what to manage the dependencies? What versions of MacOS, Xcode, and MacOS SDK? What versions of libicu and libboost_locale did you use?
Built using cmake and ninja Using MacPorts for dependencies MacOS version 10.13.6 (17G4015) Xcode Version 10.1 (10B61) SDK: 10.14 libicu: 58.2 libboost_locale: 1.66.0
ICU is in the suspect range. This might be related to the issue discussed in https://lists.gnucash.org/pipermail/gnucash-devel/2019-January/043287.html. Does test-transaction fail as described in that thread?
(Please be aware the first email in this thread is about a test hard-coded to 2018) This is the real thread for test-transaction failure https://lists.gnucash.org/pipermail/gnucash-devel/2019-January/043258.html
I've confirmed that it's the same issue: ICU's date formatter puts the wrong year on all dates between the 28th and 31st of December every year, not just 1969 as I'd originally supposed. It affects ICU versions 57 - 62, which is pretty much all current stable Linux distros.
I tried to update icu to the current version (63.1) but the old webkit required by the Mac version of GNuCash won't build with that version (a type mismatch between JSChar and UChar). I gather this bug is fixed in 63.1. If not there's no point wasting time trying to get it working. Do you know a ticket number for this bug in their bug tracker? I tried to find one but didn't so far. I could probably get webkit to build with the newer icu, but it might not be trivial. I could also try switching to webkit2. How badly is GnuCash broken with this version? If simple reports work I could probably use it. BTW MacPorts hadn't updated icu in ages since newer versions "might" require C++11 according to the comments in the port file. I don't know if they really do and I don't care anyway.
I haven't found a bug either, nor can I identify a commit that fixes it. You could fall back to ICU 55, which I use for Gnucash.app and which also works. Unfortunately we do need to work around this before the next release or it'll be broken for most Linux users. BTW, you might try converting to WebKit2--just change https://github.com/Gnucash/gnucash/blob/maint/CMakeLists.txt#L203 and accompanying else and endif to WINDOWS instead of WINDOWS OR APPLE. The test is to see if it will draw a chart.
Created attachment 373146 [details] Crash report from changing file name while printing to a file Getting GnuCash to build with Webkit2 and icu 63.1 was easy. Unfortunately it doesn't really help. The bug that displays dates near the end of December incorrectly hasn't been fixed and charts don't display. When I open a report with a chart such as Asset Chart I get no error message but the report is entirely blank. I presume that's the same behavior you see, John. On the other hand it no longer splits a line across the page boundary when printing a report but it crashes whenever I try to print to a file and change the name of the file. As soon as I enter a character in the file name field GnuCash crashes inside webkit. I've attached a crash log. I'll need to decide which set of bugs I care about the most.
I still believe there's more than 1 bug in play here. I've upgraded libicu-dev to 63.1-6 and see numerous failures in test-gnc-datetime, test-charts, test-standard-category-report, but NONE in test-transaction. All relate to date display. I'm in AWST, Australia/Perth, locale en_AU.utf8 "git revert e31f4c3f95" is my temporary bandaid
Chris, I think the test failures you're seeing are related to Summer Time. Those, like single-txn-test, that use gnc:get-start-foo and gnc:get-end-foo are using gnc_mktime with midnight; that will create a time64 with boost::date_time timezone set for that date. If boost::locale has a different understanding of Summer Time from boost::date_time its local time will be an hour different in one direction or the other and that has the potential to change the date given the use of midnight.
That changing ICU doesn't solve the problem leads me to suspect boost::locale instead of ICU, though my understanding of the boost::locale formatting is that it's just passing through to ICU. Here's an interesting commit that might be germane: https://github.com/boostorg/locale/commit/1bf387d96d151e8647f3483b695464167d5d74cd That suggests that the issue is in creating the date rather than formatting it. It's in boost 1.67 that Chris should have gotten when he upgraded to disco. Mike, can you apply it to your boost source and rebuild?
I upgraded boost to 1.69 and it fixed the problem. Did you specifically want me to try that patch to see if it is the fix? If so I can go back to 1.66 and apply the patch. It was easier to just upgrade so I did that first. At least we know it's a boost problem and that it's fixed between 1.67 and 1.69. Perhaps Chris can say if it's in 1.67 or I can go back to that version if necessary.
I'm on libboost-dev 1.67.0.1 and not quite sure how to, or if I should upgrade it in ubuntu disco :-/
Chris, up to you and you'll want to decide based on how comfortable you are with fiddling with cmake. Don't mess with the system libs. Instead get the boost sources and build and install them somewhere safe and tell cmake to look there for Boost instead of in /usr. Mike, it's up to you and your curiosity level. I think it's enough to know that it's a Boost + ICU problem (based on the minimal commit message I suppose that ICU changed something and it took a while for the boost::locale maintainer to notice). The bottom line seems to that we can't use boost::locale for formatting, both because of this issue and the time zone/DST issue. We can't reliably get a std::locale to pass to boost::date_time, so that path is blocked too. Bug 796946 seems to be about the same problem that got us here, viz. an unhandled exception because the std::locale code in MinGW64 finds Microsoft locales to be indigestible.
I'm not that curious. I don't think there is much benefit in verifying exactly which commit fixed the problem.
These are test failures, if it's any use. Note the exact failing tests differ. e.g. TZ=Australia/Perth 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:377: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "06-11-2046 15:59:59" 57: "06-11-2046 23:59:59" TZ=America/Los_Angeles (PASS) TZ=America/New_York 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:346: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "19-04-2017 23:00:00" 57: "20-04-2017 00:00:00" TZ=Europe/Berlin (PASS) TZ=Europe/London 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:346: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "19-04-2017 23:00:00" 57: "20-04-2017 00:00:00" TZ=Pacific/Honolulu (PASS) TZ=Pacific/Tongatapu (3 FAILING TESTS!) 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:346: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "19-04-2017 11:00:00" 57: "20-04-2017 00:00:00" 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:377: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "06-11-2046 10:59:59" 57: "06-11-2046 23:59:59" 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:403: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y") 57: Which is: "13-11-2045" 57: "14-11-2045" TZ=Australia/Perth 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:377: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "06-11-2046 15:59:59" 57: "06-11-2046 23:59:59" TZ=Europe/Moscow 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:377: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "06-11-2046 20:59:59" 57: "06-11-2046 23:59:59" TZ=UTC (PASS) TZ=GMT (PASS) TZ=BST 57: /home/chris/sources/gnucash/libgnucash/engine/test/gtest-gnc-datetime.cpp:377: Failure 57: Expected equality of these values: 57: atime.format("%d-%m-%Y %H:%M:%S") 57: Which is: "07-11-2046 05:59:59" 57: "06-11-2046 23:59:59" I will just need to be patient.
I like time stuff, perhaps that was why I was sent here in spite of not having a clue about the issue. Thinks for a moment: time stamps, TZ, recording, prices, actual time (who's time?) and precedence.
> who's time? Yours, until Summer Time kicks in. All times are kept in UTC and adjusted for local time on display. In general the catch is that when setting times we get local from the user's computer and have to convert that to UTC, so if there are time issues it can be at either end. In this case it's the display side.
Is there a thread about this in public? It has been known that there were odd dates and times for a while I am fortunate, I can easily correct (for an hour or so? nope) because I am in or near the boring middle. I am in the place where time or nothing depending on your perceptions exists. WTF some people voted for Trump so they are in a different TZ to me.
This is now fixed by using strftime on Windows along with a couple of locale-setting tweaks to ensure that a locale set from the environment file gets correctly setup. Unix is reverted to using std::locale and boost::date_time formatting instead of boost::locale and ICU.
