Can't reproduce, Debian 9 x86_64. (BTW it's either Vendor->New Bill or Customer->New Invoice, not that that matters). We have seen timezone issues like this in the past, though, so what TZ are you in?

I'm in the BST time zone, on arch linux

That's British Standard Time?

It is indeed, sorry if that was ambiguous.

Would this be a symptom of the issue reported in bug 794730 ? 01/01/1970 equals time64=0, which used to be taken as the invalid date in 2.6 and before, but no longer is on 2.7 and up. However parts of the code still test on this value to check whether a date was set.

For bug 794730 John fixed this yesterday for the business invoice post window though you report it for New Bill/New Invoice.

Since the fix of bug 794730, date in reports is shown properly after the invoice is posted.
However, I still get 01/01/1970 for new invoices by default and in printouts of unposted invoices.

Francois: I'm hacking scheme ie the reporting infrastructure.

Would you mind letting me know if you're using latest unstable? Which invoice template are you using - Printable Invoice, Easy Invoice, Fancy Invoice, Tax Invoice, Australian Tax Invoice? The posted/unposted invoice logic was recently changed - it was formerly testing date = MAXINT, now it is testing if the invoice has a posted account. Perhaps your invoice has an erroneous posted account?

Would you mind reviewing your AP account? If the invoice transaction exists, which date is the transaction set at?

On my current unstable in GMT+8 I have no issue. All dates ie posted/due/current are as expected.

Hi Chris,

I'm using the latest unstable indeed. I'm using the Tax invoice report and now I'm only seeing the problem when the invoice is not posted, so not in A/R yet.

I'm also seeing the problem when I go Business -> Customer -> New invoice or Business -> Vendor -> New bill. The date field in the dialogue is 01/01/1970.

The Tax Invoice (and other tax reports) logic should be sound - if invoice is in AP/AR account, then display posted + due date; if it doesn't then display "Invoice in progress...". Other bug reporters have submitted screenshots/videos; would you mind sharing?

Here it is, with the test case from bug 794730

https://drive.google.com/open?id=1OklRWhlCtghKBUaPa74AdS0dbfYfDstY

Hi Francois - I've downloaded the small Test case (7.36 KB) and found your invoice #0002, and everything checks out fine from my end. My locale is en_AU.UTF-8.

May I suggest a clean rebuild and retest? Something is certainly odd from your video.

@Jralls it would be an interesting debug tool to dump all global options, such as I've done in gnc:render-options-changed - are you aware any tool?

What do you mean by "Global Options"? The preferences? There's a tool for that on MacOS, "defaults read -a Gnucash". Gnome Desktop probably has something similar. Windows is harder because GSettings puts everything in the Registry.

Created attachment 370423 [details]
global options

In case that's what you want, this is the gsettings dump

$ gsettings list-recursively org.gnucash

Also I've tried with a fresh user account and the problem persists. Same with your locale.

Then I'm stumped; the datafile seems fine; I can't see how reports in current unstable can fail to identify the invoice as unposted; there must be something amiss in running gncInvoiceIsPosted in gncInvoice.c

Francois would you be comfortable replacing .scm files with customized debug ones?

Of course, I could even provide remote access for you if you want, but it happens on both my arch machines, so I presume you could try by yourself.

Francois - we were discussing on IRC - perhaps try the following change to gncInvoice.c as a test to determine if our (warlord geert and I) theory was sound? If you prefer the .scm equivalent I'll need to construct and come back!

libgnucash/engine/gncInvoice.c
@@ -1859,7 +1859,7 @@ gncInvoiceApplyPayment (const GncInvoice *invoice, Transaction *txn,
 gboolean gncInvoiceIsPosted (const GncInvoice *invoice)
 {
     if (!invoice) return FALSE;
-    return GNC_IS_ACCOUNT(gncInvoiceGetPostedAcc(invoice));
+    return GNC_IS_TRANSACTION(gncInvoiceGetPostedTxn(invoice));
 }
 
 gboolean gncInvoiceIsPaid (const GncInvoice *invoice)

I've just been checking the branches regarding gncInvoiceIsPosted logic:

2.7.8 was testing if posted-date = MAXINT
3.0 and unstable are currently testing if posted-acc = null
we're considering testing if posted-txn = null

Francois - can you confirm this bug still exists in latest unstable or 3.0 as pulled from current github? Because your datafile confirms the posted-date=0, and the date would be displayed as 01/01/1970 on 2.7.8, but should not be displayed in unstable.

Hi, sorry for not getting back to you earlier, I'm on a business trip.

Non-posted invoices do not show the 1970 date any more on 3.0.
However, the default date for new invoices or bills is still showing the issue.

Ok in case there's any doubt, I don't think there's any issue with the report logic anymore.

There are a few other 01-01-1970 dates in UI; some were related to timezones, or DST changes; others due to invalid dates eg year incorrectly entered as 0206. I'm afraid I can't help myself.

(In reply to John Ralls from comment #12)
> What do you mean by "Global Options"? The preferences? There's a tool for
> that on MacOS, "defaults read -a Gnucash". Gnome Desktop probably has
> something similar. Windows is harder because GSettings puts everything in
> the Registry.

On linux that would be
dconf dump /org/gnucash/

Oh and the gsettings trick should work as well.

The default date was effectively still using the wrong test to determine what date to offer.
I have fixed the test to properly detect invalid dates.
The invoice dates should now default again to today.

Thanks for reporting this.

Note: I have also changed the test for the post state as suggested in comment 19
which should also fix a slew of subtle and less subtle side effects.

Will be in gnucash 3.1.