Re: [GNC] Bad date not caught

[john]

There are two problems with that: Not everyone uses their locale date format. 
For example the US locale format is MDY but there are plenty of us former 
military types who do DMY because that's how the military does it. The other 
thing is that brain-farts happen. I enter DMY 99 44/100% of the time but every 
once in a while something happens and it goes in YMD. Sometimes it's even MDY. 

There's even a CS paradigm for this: Be liberal accepting input and strict 
formatting output.

Regards,
John Ralls


> On Oct 12, 2023, at 16:34, Stephen M. Butler  wrote:
> 
> The parser should know the local date format for the user.  That would 
> resolve the M/D/Y, D/M/Y, and Y/M/D format issue.
> 
> Stephen M Butler
> stephen.m.butle...@gmail.com
> kg...@arrl.net
> 253-350-0166
> ---
> GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8
> 
> On 10/12/23 16:27, john wrote:
>> Rather than banging on about the validity or lack thereof of 31 December 
>> 1999, which isn't really Fred's complaint, it would be more useful to 
>> explain that the date parser fires on every keystroke when typing a date in 
>> the Date Edit text box. That makes it unhelpful to raise a dialog every time 
>> the entered date isn't valid because that will be true on most of the 
>> keypresses when entering a date. Not to say that it's not feasible to do so, 
>> just that that's how it works now. There's already an event handler for when 
>> the GncDateEdit loses focus, that just needs to be wired up to know that the 
>> entered date wasn't used so it can put up a message box warning the user.
>> 
>> As I was looking through the code I saw that the intent was to use *today's* 
>> date,  not time 0, when the date didn't parse correctly. That at least will 
>> keep the duplicated transaction in view and was an easy fix, so I fixed it.
>> 
>> Another more involved fix would be to make the date parser a bit more 
>> liberal about delimiters and formats; the only slightly minor difficulty is 
>> ordering ambiguous sequences: for example 21-10-23 could be 21 October 2023 
>> or 23 October 2021 and 5/7/9 could be the 9 July 2005, 7 May 2009, or 5 July 
>> 2009.
>> 
>> Regards,
>> John Ralls
>> 
>>> On Oct 12, 2023, at 09:51, Michael or Penny Novack 
>>>  wrote:
>>> 
>>> On 10/12/2023 10:40 AM, Fred Tydeman wrote:
 In an account, I clicked on Duplicate of a transaction.
 I got a small popup with the date field highlighted.
 I typed in 5.19.21  (instead of the correct 5/19/21) and pressed enter.
 That got me the transaction duplicated, but with the
 date of 12/31/1969.
 Seems like the code should warn me about bad date.
>>> LOL --- it did, sort of.
>>> 
>>> The problem is that you didn't know the special meaning of 12/31/1969
>>> Now if the program had returned 00/00/ you would have understood that 
>>> you had a bad date. In other words, ZERO
>>> 
>>> By a convention adopted long ago, computers measure time in microseconds 
>>> since "time zero" which was chosen to be midnight, 12/31/69 (before Y2K we 
>>> tended to write years two digit if we meant in the 1900's). That makes the 
>>> "zero date" a VALID date (00/00/ would not be valid in a field 
>>> expecting a date)
>>> 
>>> Michael D Novack
>>> 
>>> 
>>> ___
>>> gnucash-user mailing list
>>> gnucash-user@gnucash.org
>>> To update your subscription preferences or to unsubscribe:
>>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>>> -
>>> Please remember to CC this list on all your replies.
>>> You can do this by using Reply-To-List or Reply-All.
>> ___
>> gnucash-user mailing list
>> gnucash-user@gnucash.org
>> To update your subscription preferences or to unsubscribe:
>> https://lists.gnucash.org/mailman/listinfo/gnucash-user
>> -
>> Please remember to CC this list on all your replies.
>> You can do this by using Reply-To-List or Reply-All.
> 
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[john]

That would be because the FAA has been trying and failing to upgrade their IT 
for darn near 50 years. MMDDYY was the standard way to code dates in the 1960s. 
Getting that fixed was what the Y2K apocalypse was about.

But while it's a nice standard that works a tread for the backends it's not 
something to impose on users. If you want to write dates as MM-DD-YY GnuCash 
should accept that.

Regards,
John Ralls

> On Oct 12, 2023, at 17:02, Dean Gibson  wrote:
> 
> Actually,, ISO8601 describes the valid (& preferred) date representations.  
> Anything with dashes is presumed to be -MM-DD.  Of course, just because 
> this is an international standard, doesn't mean that everyone (including 
> governments) follows it.  This includes the US FAA. which presumes MM-DD-YY.
> 
> So much for standards! I guess ISO8601 is pretty new (35 years ago) for some 
> organizations!
> 
> On 2023-10-12 16:27, john wrote:
>> ...
>> 
>> Another more involved fix would be to make the date parser a bit more 
>> liberal about delimiters and formats; the only slightly minor difficulty is 
>> ordering ambiguous sequences: for example 21-10-23 could be 21 October 2023 
>> or 23 October 2021 and 5/7/9 could be the 9 July 2005, 7 May 2009, or 5 July 
>> 2009.
>> 
>> Regards,
>> John Ralls
>> 
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] F::Q XAU & XAG quotes not retrieving for 2 years

[Adrien Monteleone]

Thanks. I'm not sure I want to get that deep into it.

Yes, they were created as 'currencies' and can't be changed.

I'll just manually enter prices periodically. It is only two of them.

Regards,
Adrien

On 10/12/23 8:55 PM, Ken Farley wrote:
My guess would be that it's because they were created as a "currency" 
and can't be changed? I don't use any currencies as investments, so I 
don't have any experience with this kind of thing.


If there is a way you can specify the source of the quotes (i.e. not 
Alphavantage), you could take the unusual route of making your own Perl 
module that when asked for "XAG" or "XUA", uses one of the other sources 
like yahoo_json to get the quote using their symbols and spits back a 
quote using the symbol you need. I did something like this years ago 
when my employer insisted on giving us shares in a weird Employee Stock 
Ownership Plan, whose shares were equivalent to a strange fraction of 
the company's stock price. I'd get the stock quote, multiply it by the 
fraction, and off I went.


Not an elegant solution, but it will work.



___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] F::Q XAU & XAG quotes not retrieving for 2 years

[Ken Farley]

My guess would be that it's because they were created as a "currency" 
and can't be changed? I don't use any currencies as investments, so I 
don't have any experience with this kind of thing.


If there is a way you can specify the source of the quotes (i.e. not 
Alphavantage), you could take the unusual route of making your own Perl 
module that when asked for "XAG" or "XUA", uses one of the other sources 
like yahoo_json to get the quote using their symbols and spits back a 
quote using the symbol you need. I did something like this years ago 
when my employer insisted on giving us shares in a weird Employee Stock 
Ownership Plan, whose shares were equivalent to a strange fraction of 
the company's stock price. I'd get the stock quote, multiply it by the 
fraction, and off I went.


Not an elegant solution, but it will work.
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[Adrien Monteleone]

I shudder at the thought, but it is entirely possible they were (and 
still are) 'grandfathered' in!


Regards,
Adrien

On 10/12/23 7:02 PM, Dean Gibson wrote:
This includes the US 
FAA. which presumes MM-DD-YY.


So much for standards! I guess ISO8601 is pretty new (35 years ago) for 
some organizations!


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[Dean Gibson]

Actually,, ISO8601 describes the valid (& preferred) date 
representations.  Anything with dashes is presumed to be -MM-DD.  Of 
course, just because this is an international standard, doesn't mean 
that everyone (including governments) follows it.  This includes the US 
FAA. which presumes MM-DD-YY.


So much for standards! I guess ISO8601 is pretty new (35 years ago) for 
some organizations!


On 2023-10-12 16:27, john wrote:

...

Another more involved fix would be to make the date parser a bit more liberal 
about delimiters and formats; the only slightly minor difficulty is ordering 
ambiguous sequences: for example 21-10-23 could be 21 October 2023 or 23 
October 2021 and 5/7/9 could be the 9 July 2005, 7 May 2009, or 5 July 2009.

Regards,
John Ralls


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[Stephen M. Butler]

The parser should know the local date format for the user.  That would 
resolve the M/D/Y, D/M/Y, and Y/M/D format issue.


Stephen M Butler
stephen.m.butle...@gmail.com
kg...@arrl.net
253-350-0166
---
GnuPG Fingerprint:  8A25 9726 D439 758D D846 E5D4 282A 5477 0385 81D8

On 10/12/23 16:27, john wrote:

Rather than banging on about the validity or lack thereof of 31 December 1999, 
which isn't really Fred's complaint, it would be more useful to explain that 
the date parser fires on every keystroke when typing a date in the Date Edit 
text box. That makes it unhelpful to raise a dialog every time the entered date 
isn't valid because that will be true on most of the keypresses when entering a 
date. Not to say that it's not feasible to do so, just that that's how it works 
now. There's already an event handler for when the GncDateEdit loses focus, 
that just needs to be wired up to know that the entered date wasn't used so it 
can put up a message box warning the user.

As I was looking through the code I saw that the intent was to use *today's* 
date,  not time 0, when the date didn't parse correctly. That at least will 
keep the duplicated transaction in view and was an easy fix, so I fixed it.

Another more involved fix would be to make the date parser a bit more liberal 
about delimiters and formats; the only slightly minor difficulty is ordering 
ambiguous sequences: for example 21-10-23 could be 21 October 2023 or 23 
October 2021 and 5/7/9 could be the 9 July 2005, 7 May 2009, or 5 July 2009.

Regards,
John Ralls


On Oct 12, 2023, at 09:51, Michael or Penny Novack  
wrote:

On 10/12/2023 10:40 AM, Fred Tydeman wrote:

In an account, I clicked on Duplicate of a transaction.
I got a small popup with the date field highlighted.
I typed in 5.19.21  (instead of the correct 5/19/21) and pressed enter.
That got me the transaction duplicated, but with the
date of 12/31/1969.
Seems like the code should warn me about bad date.

LOL --- it did, sort of.

The problem is that you didn't know the special meaning of 12/31/1969Now if 
the program had returned 00/00/ you would have understood that you had a 
bad date. In other words, ZERO

By a convention adopted long ago, computers measure time in microseconds since "time 
zero" which was chosen to be midnight, 12/31/69 (before Y2K we tended to write years two digit 
if we meant in the 1900's). That makes the "zero date" a VALID date (00/00/ would not 
be valid in a field expecting a date)

Michael D Novack


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[john]

Rather than banging on about the validity or lack thereof of 31 December 1999, 
which isn't really Fred's complaint, it would be more useful to explain that 
the date parser fires on every keystroke when typing a date in the Date Edit 
text box. That makes it unhelpful to raise a dialog every time the entered date 
isn't valid because that will be true on most of the keypresses when entering a 
date. Not to say that it's not feasible to do so, just that that's how it works 
now. There's already an event handler for when the GncDateEdit loses focus, 
that just needs to be wired up to know that the entered date wasn't used so it 
can put up a message box warning the user.

As I was looking through the code I saw that the intent was to use *today's* 
date,  not time 0, when the date didn't parse correctly. That at least will 
keep the duplicated transaction in view and was an easy fix, so I fixed it.

Another more involved fix would be to make the date parser a bit more liberal 
about delimiters and formats; the only slightly minor difficulty is ordering 
ambiguous sequences: for example 21-10-23 could be 21 October 2023 or 23 
October 2021 and 5/7/9 could be the 9 July 2005, 7 May 2009, or 5 July 2009.

Regards,
John Ralls

> On Oct 12, 2023, at 09:51, Michael or Penny Novack 
>  wrote:
> 
> On 10/12/2023 10:40 AM, Fred Tydeman wrote:
>> In an account, I clicked on Duplicate of a transaction.
>> I got a small popup with the date field highlighted.
>> I typed in 5.19.21  (instead of the correct 5/19/21) and pressed enter.
>> That got me the transaction duplicated, but with the
>> date of 12/31/1969.
>> Seems like the code should warn me about bad date.
> 
> LOL --- it did, sort of.
> 
> The problem is that you didn't know the special meaning of 12/31/1969Now 
> if the program had returned 00/00/ you would have understood that you had 
> a bad date. In other words, ZERO
> 
> By a convention adopted long ago, computers measure time in microseconds 
> since "time zero" which was chosen to be midnight, 12/31/69 (before Y2K we 
> tended to write years two digit if we meant in the 1900's). That makes the 
> "zero date" a VALID date (00/00/ would not be valid in a field expecting 
> a date)
> 
> Michael D Novack
> 
> 
> ___
> gnucash-user mailing list
> gnucash-user@gnucash.org
> To update your subscription preferences or to unsubscribe:
> https://lists.gnucash.org/mailman/listinfo/gnucash-user
> -
> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Closest to report date bug?

[john]

See 
https://netlicensing.io/blog/2012/06/15/set-environment-variables-in-windows-shortcut/
 for setting an environment variable, just substitute TZ=FLE Standard Time for 
LANG=en. There's a list of all of the Windows Timezone names at 
https://howtomanagedevices.com/windows-10/1774/list-of-windows-10-time-zone-codes-tzutil/,
 I picked that one because it's one of the two shortest names in +2.

Regards,
John Ralls


> On Oct 12, 2023, at 11:37, Marta Neeziak  wrote:
> 
> I'll try to figure out the TZ environment variable on my end - is there a 
> standard path where I'd find the file to be modified? For reference, I'm on 
> Windows 10.
> 
> And yes, Last Before doesn't seem to increment by date and just uses the last 
> security price found in the Price DB.
> 
> Thanks for the help.
> 
> On Thu, Oct 12, 2023 at 1:32 PM john  > wrote:
>> You can use the TZ environment variable to run GnuCash in a different 
>> timezone from the system.
>> 
>> Last Before should operate on the increment date for time series just like 
>> Closest to. Chris Lam, can you take a look at that?
>> 
>> Regards,
>> John Ralls
>> 
>>> On Oct 11, 2023, at 18:47, Marta Neeziak >> > wrote:
>>> 
>>> Thank you, this is good to know.
>>> 
>>> Unfortunately, the "Last up through report date" is not what I'm looking 
>>> for since it only shows one price across the whole report period (graph 
>>> scales up/down by units/shares, not price)...
>>> 
>>> Is there anyway for me to manually change the report time zone or price 
>>> data time zone? I don't think that this was a good change, at all, since 
>>> there is now a clear disconnect between what people will expect to see on 
>>> their screens vs. what is happening on the back end w/ time zones.
>>> 
>>> Would appreciate any support in helping me get this resolved on either my 
>>> machine (manually) or a fix globally in a new version.
>>> 
>>> Thanks again.
>>> 
>>> On Wed, Oct 11, 2023 at 8:35 PM john >> > wrote:
 
 
 > On Oct 11, 2023, at 09:17, Marta Neeziak >>> > > wrote:
 > 
 > Not sure what's going on here - but I updated to 5.4 last week and have
 > since had issues with generating graphs that use "Closest to report date"
 > for price data.
 > 
 > Basically, when I have the price of an asset and I try to graph it - it
 > graphs the asset using the following day's price data. Example: A stock 
 > is
 > worth $10 Day0, $10 Day1, $20 Day2, and $10 Day3 - GNUCash will display a
 > price of $20 on Day1 and $10 on all other days. I spun up a new db to 
 > test
 > this, and can't seem to figure it out...
 > Results: https://imgur.com/a/fjmwnHc
 > 
 > If anyone has any idea as to what's going on and how to fix this, I'd
 > really appreciate it. Thank you.
 
 It's because the report time is midnight local and the quote time is  now 
 neutral time (10:59 UTC) so that the price will have the same date in all 
 timezones. Unless your time zone is east of UTC+2 (Central European 
 Standard Time) 10:59Z the next day is closer to midnight than 10:59Z 
 today. Use "Last up through report date" to align the prices the way you 
 want.
 
 Regards,
 John Ralls
 
 
>> 

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Closest to report date bug?

[Marta Neeziak]

I'll try to figure out the TZ environment variable on my end - is there a
standard path where I'd find the file to be modified? For reference, I'm on
Windows 10.

And yes, Last Before doesn't seem to increment by date and just uses the
last security price found in the Price DB.

Thanks for the help.

On Thu, Oct 12, 2023 at 1:32 PM john  wrote:

> You can use the TZ environment variable to run GnuCash in a different
> timezone from the system.
>
> Last Before should operate on the increment date for time series just like
> Closest to. Chris Lam, can you take a look at that?
>
> Regards,
> John Ralls
>
> On Oct 11, 2023, at 18:47, Marta Neeziak  wrote:
>
> Thank you, this is good to know.
>
> Unfortunately, the "Last up through report date" is not what I'm looking
> for since it only shows one price across the whole report period (graph
> scales up/down by units/shares, not price)...
>
> Is there anyway for me to manually change the report time zone or price
> data time zone? I don't think that this was a good change, at all, since
> there is now a clear disconnect between what people will expect to see on
> their screens vs. what is happening on the back end w/ time zones.
>
> Would appreciate any support in helping me get this resolved on either my
> machine (manually) or a fix globally in a new version.
>
> Thanks again.
>
> On Wed, Oct 11, 2023 at 8:35 PM john  wrote:
>
>>
>>
>> > On Oct 11, 2023, at 09:17, Marta Neeziak 
>> wrote:
>> >
>> > Not sure what's going on here - but I updated to 5.4 last week and have
>> > since had issues with generating graphs that use "Closest to report
>> date"
>> > for price data.
>> >
>> > Basically, when I have the price of an asset and I try to graph it - it
>> > graphs the asset using the following day's price data. Example: A stock
>> is
>> > worth $10 Day0, $10 Day1, $20 Day2, and $10 Day3 - GNUCash will display
>> a
>> > price of $20 on Day1 and $10 on all other days. I spun up a new db to
>> test
>> > this, and can't seem to figure it out...
>> > Results: https://imgur.com/a/fjmwnHc
>> >
>> > If anyone has any idea as to what's going on and how to fix this, I'd
>> > really appreciate it. Thank you.
>>
>> It's because the report time is midnight local and the quote time is  now
>> neutral time (10:59 UTC) so that the price will have the same date in all
>> timezones. Unless your time zone is east of UTC+2 (Central European
>> Standard Time) 10:59Z the next day is closer to midnight than 10:59Z today.
>> Use "Last up through report date" to align the prices the way you want.
>>
>> Regards,
>> John Ralls
>>
>>
>>
>
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Closest to report date bug?

[john]

You can use the TZ environment variable to run GnuCash in a different timezone 
from the system.

Last Before should operate on the increment date for time series just like 
Closest to. Chris Lam, can you take a look at that?

Regards,
John Ralls

> On Oct 11, 2023, at 18:47, Marta Neeziak  wrote:
> 
> Thank you, this is good to know.
> 
> Unfortunately, the "Last up through report date" is not what I'm looking for 
> since it only shows one price across the whole report period (graph scales 
> up/down by units/shares, not price)...
> 
> Is there anyway for me to manually change the report time zone or price data 
> time zone? I don't think that this was a good change, at all, since there is 
> now a clear disconnect between what people will expect to see on their 
> screens vs. what is happening on the back end w/ time zones.
> 
> Would appreciate any support in helping me get this resolved on either my 
> machine (manually) or a fix globally in a new version.
> 
> Thanks again.
> 
> On Wed, Oct 11, 2023 at 8:35 PM john  > wrote:
>> 
>> 
>> > On Oct 11, 2023, at 09:17, Marta Neeziak > > > wrote:
>> > 
>> > Not sure what's going on here - but I updated to 5.4 last week and have
>> > since had issues with generating graphs that use "Closest to report date"
>> > for price data.
>> > 
>> > Basically, when I have the price of an asset and I try to graph it - it
>> > graphs the asset using the following day's price data. Example: A stock is
>> > worth $10 Day0, $10 Day1, $20 Day2, and $10 Day3 - GNUCash will display a
>> > price of $20 on Day1 and $10 on all other days. I spun up a new db to test
>> > this, and can't seem to figure it out...
>> > Results: https://imgur.com/a/fjmwnHc
>> > 
>> > If anyone has any idea as to what's going on and how to fix this, I'd
>> > really appreciate it. Thank you.
>> 
>> It's because the report time is midnight local and the quote time is  now 
>> neutral time (10:59 UTC) so that the price will have the same date in all 
>> timezones. Unless your time zone is east of UTC+2 (Central European Standard 
>> Time) 10:59Z the next day is closer to midnight than 10:59Z today. Use "Last 
>> up through report date" to align the prices the way you want.
>> 
>> Regards,
>> John Ralls
>> 
>> 

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[Michael or Penny Novack]

On 10/12/2023 10:40 AM, Fred Tydeman wrote:

In an account, I clicked on Duplicate of a transaction.
I got a small popup with the date field highlighted.
I typed in 5.19.21  (instead of the correct 5/19/21) and pressed enter.
That got me the transaction duplicated, but with the
date of 12/31/1969.
Seems like the code should warn me about bad date.


LOL --- it did, sort of.

The problem is that you didn't know the special meaning of 12/31/1969    
Now if the program had returned 00/00/ you would have understood 
that you had a bad date. In other words, ZERO


By a convention adopted long ago, computers measure time in microseconds 
since "time zero" which was chosen to be midnight, 12/31/69 (before Y2K 
we tended to write years two digit if we meant in the 1900's). That 
makes the "zero date" a VALID date (00/00/ would not be valid in a 
field expecting a date)


Michael D Novack


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] Bad date not caught

[Derek Atkins]

Hi,

On Thu, October 12, 2023 10:40 am, Fred Tydeman wrote:
> In an account, I clicked on Duplicate of a transaction.
> I got a small popup with the date field highlighted.
> I typed in 5.19.21  (instead of the correct 5/19/21) and pressed enter.
> That got me the transaction duplicated, but with the
> date of 12/31/1969.
> Seems like the code should warn me about bad date.

What is "bad" about 12/31/1969?  Do you have something against the 60s? 
Something against new year's eve?  Or just don't like the coming 1970s?  A
"Bad Date" (in this context -- not some nightmarish dinner-and-a-movie
horror) would be "12/32/1969".

In all seriousness, GnuCash can't necessarily know if you MEANT to type
12/31/1969 or if it's due to the parsing of your input that results in
'0'.  Clearly, 12/31/1969 is not what you INTENDED, but I wouldn't
necessarily say it is a "bad date".

Having said that, there IS code in GnuCash that prevents adding new
transactions earlier than some specified historic period (e.g. 90 days
ago).  If you have that feature turned on (it is NOT turned on by default)
and this happened, then that would absolutely be a bug.

> I am running GnuCash 4.14
> on Linux Fedora 37

> Please remember to CC this list on all your replies.
> You can do this by using Reply-To-List or Reply-All.

-derek

-- 
   Derek Atkins 617-623-3745
   de...@ihtfp.com www.ihtfp.com
   Computer and Internet Security Consultant

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[GNC] Bad date not caught

[Fred Tydeman]

In an account, I clicked on Duplicate of a transaction.
I got a small popup with the date field highlighted.
I typed in 5.19.21  (instead of the correct 5/19/21) and pressed enter.
That got me the transaction duplicated, but with the
date of 12/31/1969.
Seems like the code should warn me about bad date.

I am running GnuCash 4.14
on Linux Fedora 37
___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

[GNC] tax report for india

[Paras Desai]

Hello Adrien,

Thanks for your reply. Much appreciate.

I was running the transaction report, without selecting child account (I 
assumed that by selecting “Income” account all children accounts would 
be selected automatically, but that was not the case). I selected all 
the children accounts (there is a separate Tab for the same in 
Transaction report) and I could generate the report, which is close to 
what I had expected.


I also tried to run the Account Summary report, which was cleaner and 
concise, (though I had to select individual “Taxable Income” 
separately), but it could not generate the Grand Total.


Yes, I am aware that I can filter based on the note/description text to 
generate the tax report, as you kindly highlighted. But I always fear, 
if I may miss tagging a particular transaction as Taxable while posting, 
and eventually it may lead to an error in figures I get. So I chose 
little foolproof way, though I have to make few extra entries, but it is 
OK for me!


Thanks again for your suggestion and wish, one day we will see a tax 
report for India too !!


With my best regards


Paras

___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.

Re: [GNC] macOS Sonoma "Gnucash is damaged and can’t be opened" error

[Adrien Monteleone]

I'm suspicious of a missing step.

Did you *install* Gnucash, or just download the .dmg file and open it, 
then click Gnucash.app?


The .dmg file, when opened should have a shortcut to /Applications to 
make it handy to drag the Gnucash.app file over it for installation, and 
even has an arrow prompting you to do so. (you can drag and drop the 
.app file wherever you like in your home folder, but /Applications is 
traditional for all users to have access to it)


Pretty much *all* mac software is installed this way if contained in a 
manually downloaded .dmg. (the App Store does this for you 
automatically, but no, GnuCash is not distributed through the App Store)


Regards,
Adrien

On 10/11/23 6:49 AM, Vincent Lucarelli wrote:

I downloaded the image directly from the link on the gnucash.org 
 homepage.

I did try to run the fq updater from the command line before double clicking 
the Gnucash.app - could that have caused the whole app to be marked with 
quarantine?



On Oct 10, 2023, at 05:05, Vincent Lucarelli  
wrote:

I upgraded an Intel Mac to macOS Sonoma and downloaded Gnucash 5.4.  When I tried to 
run it, I got the error "Gnucash is damaged and can’t be opened.”

In previous OS versions, there was an error about untrusted developer and in 
System Settings you could approve running the application. System Settings has 
been reorganized and I could not find anywhere to approve Gnucash.

In the terminal, I ran

xattr -rds com.apple.quarantine /Applications/Gnucash.app

and then has to launch Gnucash twice for it to finally run.


___
gnucash-user mailing list
gnucash-user@gnucash.org
To update your subscription preferences or to unsubscribe:
https://lists.gnucash.org/mailman/listinfo/gnucash-user
-
Please remember to CC this list on all your replies.
You can do this by using Reply-To-List or Reply-All.