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 791825 - Accounting Period dates (among others) stored with a TZ-sensitive time.
Accounting Period dates (among others) stored with a TZ-sensitive time.
Status: RESOLVED OBSOLETE
Product: GnuCash
Classification: Other
Component: General
2.7.x
Other Windows
: Normal normal
: ---
Assigned To: gnucash-general-maint
gnucash-general-maint
Depends on:
Blocks:
 
 
Reported: 2017-12-20 10:07 UTC by Alen Siljak
Modified: 2018-06-30 00:01 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Alen Siljak 2017-12-20 10:07:37 UTC 
- uninstall GnuCash 2.6.19
- delete user profile
- install 2.7.2
- run

The app opens my default book.
Accounting period was previously (in 2.6.18) set to Australian settings -> 2017-07-01 to 2018-06-30.
Now showing as 2017-06-30 to 2018-06-29.

I've already manually modified them to the correct settings.

Not sure now if this is just a display issue or if the settings are stored/read wrongly.
Will need to check the reports and filters.
Comment 1 John Ralls 2018-01-10 02:06:57 UTC 
Indeed, I can get it to do that by changing timezones in unstable. It appears to be storing a time64 and it's probably midnight local instead of 10:59Z. Now to track it down...
Comment 2 John Ralls 2018-03-20 21:59:33 UTC 
The problem is that the date editor's "time" property is tied directly to the preference item and it sets a timestamp for 00:00:01 local, so if you set the property during standard time it will change the date at DST or if you change TZ to the west.

A quick solution would be to make gnc_date_edit_get_date() return gnc_dmy2time64neutral(), which would apply the time used in transactions (10:59:59 Z) to all bare dates. For reports we would want to re-set the times to be 00:00:01 local for the start day and 23:59:59 for the end day, but that could be handled in the report option code and it would benefit from having a universally consistent way of knowing what data the timestamp applies to.
Comment 3 John Ralls 2018-04-28 20:38:29 UTC 
I think the immediate cause of the reported problem is that the time zone calculation on Windows was screwed up causing the timezone to be shifted one zone to the west and so the stored date changed. The problem is explored in more detail in bug 795405. That problem is fixed in GnuCash 3.1.

However, the problem described in comment 2 remains, so leaving this bug open with a new title.
Comment 4 John Ralls 2018-06-30 00:01:53 UTC 
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=791825. Please continue processing the bug there and please update any external references or bookmarks.