The first fix for this bug handled structs tm with ambiguous times.
This one fixes the GncDate constructor when the time is ambiguous
because it's in the DST-change hour, using the same add 3 hours,
construct the LDT, and subtract the 3 hours from the result.
The string constructor handles only simple-offset HH:MM timezones and so
is immune to the bug.
Drop translations of the 'gnucash-icon' string from our po files
and add a note for translators to not translate this string or
use the litteral 'gnucash-icon' as translation
We only used strfmon in one source file to generate three fixed format
strings. Instead of updating to a newer strfmon in borrowed I have
chosen to reimplement the string formatters for these strings in C++.
Note this is *not* a full c++ conversion of the full functionality
of assistant-loan. Only the string parsing has been redone.
Change all instances of bugzilla.gnome.org to bugs.gnucash.org, reflecting
our migration to a self-hosted bug tracker.
Inform the Translation Project Coordinator at release that this affects
translatable strings and that all message catalogs have been updated.
Restores the gncmod-python module.
It removes the need to link the module to libgncmod-app-utils.dylib or
libgncmod-core-utils.dylib. This was needed previously as the init
function for those modules was called in the c code. However, unless
there was python c code at some point in gncmod-python.c to use
functions in c of either core utils or app utils these are not needed.
Those module init functions would be called when the modules are
imported in eg init.py, which does indeed import _sw_app_utils
successfully.
I have made edits to init.py (and other files) so it loads without
errors with python 3. These edits are NOT tested. I dont actually use
pycons, I update the init.py to simply import my python subsystem init
module. I never set the if False: to if True: to actually activate the
console.
Instead of reporting an error and declining to load the file (XML)
or failing to enter a value (SQL) when a bad date is found in the
database, use a 0 time stamp (1970-01-01 00:00:00 UTC). Adds a warning
in SQL backends; there was one already in XML.
Also Bug 791825 - Accounting Period dates off by 1.
The DST start/end dates were reversed *and* the DST offset had the wrong
sign in Windows, resulting in the effective timezone always being one to
the west off (i.e. PDT was -9 and PST was -8).