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 724211 - Can't select march 6 date on register
Can't select march 6 date on register
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Register
2.6.1
Other Windows
: Normal normal
: ---
Assigned To: gnucash-ui-maint
gnucash-ui-maint
: 725406 725447 725585 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-02-12 07:55 UTC by Cristian Marchi
Modified: 2018-06-29 23:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Cristian Marchi 2014-02-12 07:55:30 UTC
Just try to enter a transaction on March 6 (any year, any register) and you'll notice that the date is not selected. That happens under Win XP and GnuCash 2.6.1. Haven't tried yet under linux.
Comment 1 clinton 2014-02-12 13:29:57 UTC
I am on GnuCash 2.6.1 but on Windows 7.  I can enter March 6 in any year but CANNOT enter March 3 of any year.  When I try to enter March 3, it displays March 2.
Comment 2 Cristian Marchi 2014-02-13 20:00:48 UTC
I tested if the bug apply also on linux system and I can't reproduce it (Ubuntu 13.10 64bit and GnuCash 2.6.1)
Comment 3 Olly Gamester 2014-02-19 16:20:30 UTC
I agree ... with 2.6.1 and WinXP, I cannot enter 6 March as a transaction date.  Entering 7 March, then pressing the - key jumps the date to 5 March.  Entering 5 March then pressing the + key does nothing.
Comment 4 Stefano Fiorini 2014-02-19 16:28:01 UTC
I can confirm bug for March 6 on version 2.6.1 under Windows 7.... but for me no problem with March 3
Comment 5 clinton 2014-02-19 17:05:59 UTC
Interesting.  More info for my issue:
I can still enter March 6 but cannot enter March 3.
If I enter a date prior, say February 27 and use the plus key (+) it will increment to March 2 and then will not increment any further.  If I enter a later date, say March 10 and use the minus key (-) it will decrement to March 4, then skips March 3 and instead goes to March 2 and continues from there.  Entering March 3 directly always goes to March 2.
I am on GnuCash 2.6.1, built from git rev abbd3ab+ on 2014-01-27
I am running Windows 7 Professional, Service Pack 1, 64 bit
Comment 6 Geert Janssens 2014-02-19 17:35:01 UTC
Confirmed on my Windows XP test box, but for yet another date: March 5...

Not reproducible on linux so this really seems to be a Windows only bug.
Comment 7 Geert Janssens 2014-02-20 17:15:39 UTC
Played a bit further. Downloaded and installed today's nightly build.

This one is crashing out right when I try to go from March 5 to March 6 or anything beyond this date. This is worse than what we so far.

There is nothing in the trace file. But when I make gnucash a console program (using the exetype tool) it prints a clue on the console (this doesn't get logged to the trace file):

GLib:ERROR:gtimezone.c:195:g_time_zone_ref: assertion failed: (tz->ref_count > 0)

And now I need help to debug this further :(

I have run gnucash under gdb on windows, but it doesn't break on the assertion. The program just ends with error code 03.

How to proceed from here ?
Comment 8 Geert Janssens 2014-02-20 18:00:10 UTC
I reinstalled 2.6.1 release, set exectype to console and reran the test.

The date edit still stalls on March 5 (can't move to March 6 using the + key), but the GLib error doesn't happen. And dates after March 6 can be entered again. So I think we're looking at two bugs here

- impossible to move to March 6 on Windows (no clues as to why)
- GLib tz assertion failure starting from March 6

The second may be related to the first. I suspect the second one got introduced when we started caching the local timezone.
Comment 9 Geert Janssens 2014-02-20 22:12:58 UTC
Running gnucash in gdb now...

I'm pretty sure the daylight saving time handling on Windows is broken. I'm not sure how just yet. March 6 is the date my timezone shifts from standard time to daylight saving time according to my Windows XP test box.

Because GTimeZone is not working properly (according to comments in the gnc-date.c code) a lot of workaround code is ifdef'd for Windows.

I have at least found the cause of the crash. I'm not too sure what the best fix is though because the date-time handling seems to be rather complex and subtle.

Anyway, where the crash happens:
- entering a date somewhere in GnuCash eventually ends up in
  qof_print_date_dmy_buff (gnc-date.c:881)
- if locale date format is chosen (a condition to trigger the bug imo) this will call gnc_mktime which eventually will call gnc_g_date_time_new_local
- the first line of this function defines a local tz variable and points it to the static (cached) tz timezone.
- a few lines later gnc_g_time_zone_adjust_for_dst is called. On Windows this function does much more than on linux or OS X. If this function detects we're in the dst interval, it *unrefs* the current tz pointer (which still points at the static tz)
- then it creates a new tz which it returns
- in gnc_g_date_time_new_local this new tz is assigned to the local tz variable
=> the static tz is still unref'd at this point if I understand it correctly.
So any subsequent call that will unref that pointer will trigger the above assert.

I'm not sure what the proper solution is though. I first thought that maybe each function that currently still stores a local GTimeZone tz should instead directly use the static tz (which should be made global in the gnc-date file then). But when continuing through the date parsing I'm not so sure this won't cause a timezone that shifts one hour with each call to gnc_g_time_zone_adjust_for_dst.

I'll have to leave this to John for further investigation.
Comment 10 Geert Janssens 2014-02-21 11:43:16 UTC
The trouble date is timezone dependent. My typical timezone is CET - GMT+01:00. With that TZ set, March 6 can't be selected.

When I change my TZ to Central Time (US&Canada) - GMT-06:00 - March 3 can't be selected like Clinton experienced in comment 3.

This issue goes back to at least gnucash 2.5.10-something. That was the version I was testing when I replied in comment 6. I am not sure anymore March 5 was the problem date in that version. I have since replaced my version with 2.6.1 so I can't retry easily. It probably doesn't matter even.
Comment 11 John Ralls 2014-02-22 01:10:12 UTC
I think I found the problem: I hadn't handled Windows TIME_ZONE_INFO correctly. When I fixed that the problem went away. Not only that, but the DST transitions are on the right day now.

50c6419 in master. Please test on tomorrow's nightlies.
Comment 12 Geert Janssens 2014-02-22 11:25:13 UTC
Works like a charm on my test system. Thanks a lot for getting this fixed!
Comment 13 John Ralls 2014-02-28 16:58:58 UTC
*** Bug 725406 has been marked as a duplicate of this bug. ***
Comment 14 Mike Evans 2014-03-02 09:24:58 UTC
*** Bug 725447 has been marked as a duplicate of this bug. ***
Comment 15 John Ralls 2014-03-03 16:07:18 UTC
*** Bug 725585 has been marked as a duplicate of this bug. ***
Comment 16 John Ralls 2018-06-29 23:26:25 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=724211. Please update any external references or bookmarks.