GNOME Bugzilla – Bug 699977
Since last run assistant using wrong time zone in release 2.5.1
Last modified: 2018-06-29 23:15:53 UTC
Starting in release 2.5.1 the Since last run assistant appears to be using Universal time rather than local time. When it is around 8:00 pm or later Central daylight time (my local time zone) the Since last Run assistant wants to enter a transaction that should not be entered until tomorrow. If I re-install 2.4.13, the Since Last Run assistant correctly states that the same SX should be entered tomorrow. For this experiment I am running GnuCash in Windows 7 Pro 64 bit.
The specific transaction is set to remind in advance 70 days ahead on July 18, 2013. It was about 9:00 pm CDT June 8 when release 2.5.1 made the reminder appear. Judging by the timestamp on this bug, Universal time is 5 or so hours faster than Central Daylight time.
That is interesting, I am sure I am using the existing code, I wonder if it is related to some changes to use GDate. I will dig around.
This is likely a duplicate of bug 704039, for which a fix has just been committed. Can you test if gnucash 2.5.4 will fix this issue ? (Note 2.5.4 is to be released one of the coming days).
Perhaps you mean 2.5.6? In any case, release 2.4.13 in Windows entered about 40 transactions scheduled for the last day of the month on August 30, so I guess it was broken there too. I am out of town so I will not be testing 2.5.6 until sometime after September 7.
That will actually be 2.5.5 ;) It hasn't been released yet, so after September 7 is fine.
Maybe last day of the month uses a different clock than numeric date?
Well!!! I am using version 2.4.11 in Ubuntu 12.04 to look at a file that I normally process in Windows 7 64 bit. Here, all of the existing end of the month transactions are dated one day early. They are all a day early going back even to a few dated in 1992. The only other odd thing is that I am presently in Las Vegas and I have temporarily set my Ubuntu computer clock to Pacific Time instead of Central Time where I live. They were all correctly dated in the Windows environment. I will try looking at this file which has now been edited in Ubuntu on another computer running windows.
The exact same file shows transactions created by the Since Last Run assistant on a Windows machine are showing one day early when viewed on this Ubuntu machine running 2.4.11, while they are correctly displayed when viewed in Windows. The transactions manually changed from August 30 to August 31 in Linux still appear as August 31 when viewed in the Windows environment.
I forgot to mention that the version in the Windows machine is still 2.4.13.
It is 8:03 pm Central Daylight Time and the Since Last Run assistant wants to enter a transaction that is programmed to be entered 70 days before November 20, 2013. That is 70 days and 4 hours from now. This is using release 2.5.5 in Windows 7 64 bit. Right now this computer is set to display CDT. (UTC -6:00)
In comment 10 I forgot to explicitly state that I am confirming that GnuCash is still using UTC.
Seems related to bug 711289
David, can you re-test this with 2.5.8? If it still fails, are you able to build trunk?
John, this is on Windows ;) David can download the latest nightly build from http://code.gnucash.org/builds/win32/trunk/ ... except that the windows builds have failed for the past two nights due to Mike's work on gzip. But that's unrelated to this bug.
I have fixed the issues that broke the windows builds. David: can you try the most recent nightly build (as of November 20) and see if this fixes the timezone issues ? Nightly builds can be found here: http://code.gnucash.org/builds/win32/trunk/
P.S. I manually restarted the nightly build this morning, so the build you find for November 20 is one containing the fixes.
A month later, no complaints, the fix must have worked.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=699977. Please update any external references or bookmarks.