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 711289 - time zone handling is inconsistent between 2.4 and 2.5
time zone handling is inconsistent between 2.4 and 2.5
Status: VERIFIED FIXED
Product: GnuCash
Classification: Other
Component: Engine
2.5.x
Other Windows
: Normal major
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks: 699977
 
 
Reported: 2013-11-02 14:24 UTC by Kuang-che Wu
Modified: 2018-06-29 23:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Kuang-che Wu 2013-11-02 14:24:14 UTC 
How to reproduce:
0. My time zone is GMT+8. On windows xp. I use gnucash sqlite backend.
1. Use gnucash 2.4.13, enter a transaction (A) at date 2013/10/25. And close gnucash.
2. Open gnucash 2.5.6, see the transaction (A) in register (both old and new have the same problem). Found the date becomes 2013/10/24 !!
3. Enter another trsanction (B) at date 2013/10/25.


If dumpping the sqlite database directly,
the post_date of transaction (A) is '20131024160000',
the post_date of transaction (B) is '20131025000000'
Looks like 2.4 store the datetime using UTC time, but 2.5 use local time.

I know Bug 137017 is not yet resolved. However, the handling should be consistent between versions anyway (unless it is intentional).

I think this bug is the root cause of Bug 707491 - gnucash chart date off by one day
Comment 1 John Ralls 2013-11-12 18:32:02 UTC 
I set the TZ to Tokyo in a Win7 VM and started GC. Tokyo time was about 0230 13 November, but the default date for a new txn in the register was 12 November. That implies the problem isn't in storing or retrieving the date from the database, it's in retrieving the time from the system.

This seems to be a Win32-only problem.
Comment 2 Geert Janssens 2013-11-14 14:07:22 UTC 
Bug 699977 may be related.
Comment 3 John Ralls 2013-11-15 19:41:39 UTC 
Well, I found one problem with the Windows TZ code. It was formatting the offset string incorrectly so that it wasn't recognized by g_time_zone_new(). Fixing that gets us about 75% of the way, and probably fixes 699977 as well.

But when one starts up GC, the blank txn is showing the wrong date, and I don't see where it's coming from. It isn't what's getting set in info->last_date_entered. I put a PWARN on that and it's the correct value.
Comment 4 John Ralls 2013-11-20 03:15:55 UTC 
Found it! r23414.
Comment 5 Kuang-che Wu 2013-11-21 16:30:08 UTC 
Thanks, the nightly build works.
Comment 6 John Ralls 2018-06-29 23:20:45 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=711289. Please update any external references or bookmarks.