On 7/19/08, Charles Day <[EMAIL PROTECTED]> wrote:
>
> I'm going to go ahead and throw out another proposal for comments. I'm
> calling this RFC2. Unless specifically stated, all that follows refers to
> transaction posting dates and times only.
>
> Since to my knowledge the feature of having a "ti
I'm going to go ahead and throw out another proposal for comments. I'm
calling this RFC2. Unless specifically stated, all that follows refers to
transaction posting dates and times only.
Since to my knowledge the feature of having a "time zone per account" has
not actually been requested by any us
On Fri, Jul 18, 2008 at 3:24 PM, Mike or Penny Novack <
[EMAIL PROTECTED]> wrote:
>
> The key is that the register would display date,time, AND TIMEZONE. The
>> timezone lets the user recognize that ...
>>
>>
>
> I am going to ask again.
>
> On July 18th at 14:30 EST the bookkeeper enters a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been using the "new" gnucash for many months now and thought I
would give some feedback on how I like it.
Overall, it is continues the great improvements that I have seen over
the years that I have been using it.
One small thing that I would cha
Meant to include the list.
--- On Fri, 7/18/08, David T. <[EMAIL PROTECTED]> wrote:
> From: David T. <[EMAIL PROTECTED]>
> Subject: Re: RFC: Timestamps/timezones proposal
> To: "Derek Atkins" <[EMAIL PROTECTED]>
> Date: Friday, July 18, 2008, 4:53 PM
> Derek, when I look at bug 89439, I see that
Mike or Penny Novack wrote:
>
>> The key is that the register would display date,time, AND TIMEZONE.
>> The timezone lets the user recognize that ...
>>
>>
>
> I am going to ask again.
>
> On July 18th at 14:30 EST the bookkeeper enters a transaction
> involving accounts whose "time zones"
>The key is that the register would display date,time, AND TIMEZONE. The
>timezone lets the user recognize that ...
>
>
I am going to ask again.
On July 18th at 14:30 EST the bookkeeper enters a transaction involving
accounts whose "time zones" are all also EST (in other words there wil
On Fri, Jul 18, 2008 at 12:36 PM, Stuart D. Gathman <[EMAIL PROTECTED]>
wrote:
> Charles Day wrote:
>
>> Under what circumstances would an end user ever choose the option
>>> "randomly
>>> change the dates on my transactions when I change the timezone on my
>>> machine"?
>>>
>>>
>> Tell me how thi
Charles Day wrote:
>> Under what circumstances would an end user ever choose the option "randomly
>> change the dates on my transactions when I change the timezone on my
>> machine"?
>>
> Tell me how this proposal would cause "random" date changes. Only the
> *display* of the timestamp changes
Ian Lewis wrote:
> I'm curious though, and maybe you can fill me in, is the reason that
> the timestamp is important that, from an accounting standpoint, the
> transaction occurred on the day (in the timezone) that it was entered
> into the register? Meaning that the date is June 6 because it was
>
Quoting "David T." <[EMAIL PROTECTED]>:
> Charles, I believe Graham is right on this. I can easily see the
> end-user scenario that he outlines, and I agree with him that the
> transaction date is a DATE. All the confusion about UTC, timezones,
> account settings and the such GO AWAY if the tra
Charles, I believe Graham is right on this. I can easily see the end-user
scenario that he outlines, and I agree with him that the transaction date is a
DATE. All the confusion about UTC, timezones, account settings and the such GO
AWAY if the transaction is a date. Moreover, throughout all of t
On Fri, Jul 18, 2008 at 11:29 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Graham Leggett <[EMAIL PROTECTED]> writes:
>
> > Charles Day wrote:
> >
> >> Tell me how this proposal would cause "random" date changes. Only
> >> the *display* of the timestamp changes, and only according to
> >> setting
Graham Leggett <[EMAIL PROTECTED]> writes:
> Charles Day wrote:
>
>> Tell me how this proposal would cause "random" date changes. Only
>> the *display* of the timestamp changes, and only according to
>> settings that you pick yourself.
>
> Try this:
>
> Enter a transaction dated 1 March 2008 in an
On Fri, Jul 18, 2008 at 11:18 AM, Mike Alexander <[EMAIL PROTECTED]> wrote:
> --On July 18, 2008 7:18:06 PM +0200 Graham Leggett <[EMAIL PROTECTED]>
> wrote:
>
> If a timestamp is used, it means that every single piece of time
>> related code, must correctly respect the account timezone, at all
>
On Fri, Jul 18, 2008 at 10:18 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Charles Day wrote:
>
> Tell me how this proposal would cause "random" date changes. Only the
>> *display* of the timestamp changes, and only according to settings that you
>> pick yourself.
>>
>
> Try this:
>
> Enter a
--On July 18, 2008 7:18:06 PM +0200 Graham Leggett <[EMAIL PROTECTED]>
wrote:
> If a timestamp is used, it means that every single piece of time
> related code, must correctly respect the account timezone, at all
> times moving forward during development.
>
> As soon as *one* developer at *any* t
Charles Day wrote:
Tell me how this proposal would cause "random" date changes. Only the
*display* of the timestamp changes, and only according to settings that
you pick yourself.
Try this:
Enter a transaction dated 1 March 2008 in an account with timezone
UTC+02, with its split in a second
On Fri, Jul 18, 2008 at 9:23 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Charles Day wrote:
>
> No, splits don't have posting dates or times. The entire transaction uses
>> a single timestamp. That's how it works now. Under this proposal, that
>> timestamp would only be *displayed* differentl
Hi,
On Freitag, 18. Juli 2008, [EMAIL PROTECTED] wrote:
[...]
> So my question is: Are there any plans/possibilities, to see this protocol
> in gnucash any time?
[...]
As far as AqBanking is concerned: Most likely not.
It's not that I don't want to, the reason is the STUZZA (which is the
organi
Charles Day wrote:
No, splits don't have posting dates or times. The entire transaction
uses a single timestamp. That's how it works now. Under this proposal,
that timestamp would only be *displayed* differently in different
registers, or not, according to your preference.
This is still very
On Fri, Jul 18, 2008 at 9:01 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 18, 2008 at 3:46 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:
>
>> Charles Day wrote:
>>
>> ok, though what happens when the user decides to change the timezone for
account A? (eg. I ask the bank to transf
On Fri, Jul 18, 2008 at 3:46 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Charles Day wrote:
>
> ok, though what happens when the user decides to change the timezone for
>>> account A? (eg. I ask the bank to transfer my account from their Saint
>>> John's branch to their Vancouver branch, 5 ti
Hi all,
on Friday 18 July 2008 12:37, [EMAIL PROTECTED] wrote:
> Dear Team,
>
> the financial companies in Austria had their own
> idea how the communication should work and they
> created their own standard: MBS/IP (Downloadable at www.stuzza.at)
> So there is only one program existent (ELBA) wh
When does it break?
Every time the computer's time zone is changed, the time stamps of
every transaction in the file get updated relative to the new time
zone. This is dumb. This is broken.
In what world does traveling change the past? Not this one.
With gnucash, traveling does change
Dear Team,
the financial companies in Austria had their own
idea how the communication should work and they
created their own standard: MBS/IP (Downloadable at www.stuzza.at)
So there is only one program existent (ELBA) which supports this standard.
(It is a Java program but they managed it to get
Charles Day wrote:
ok, though what happens when the user decides to change the timezone for
account A? (eg. I ask the bank to transfer my account from their Saint
John's branch to their Vancouver branch, 5 timezones apart?) What happens to
the timestamps and dates displayed then?
The timestamp
Ian Lewis wrote:
>I kind of understand where Stuart is going with this. There are a lot
>of parallels. The currency example is one. From a programming
>perspective, storing strings without an encoding is another.
>Essentially to know the real value you need to know another piece of
>metadata.
>
>S
Ian Lewis wrote:
In other words, the
timezone in which it was entered needs to be stored to figure out what
day it was entered? Otherwise, wouldn't the local timezone be enough
to serve as metadata when converting to a date?
The local timezone changes over time, and this is the source of the
Hi Jerry,
Jerry Jaskierny wrote:
> With what frequency do Gnucash bugs get Triaged?
Wow, you are impatient. The bug is what, like two days old?
/me is unaffected anyway
But to respond to your question. Bugs get triaged whenever somebody
skilled enough has the time and feels like doing it. The
With what frequency do Gnucash bugs get Triaged?
http://bugzilla.gnome.org/show_bug.cgi?id=543049 appears to stop
users (including myself) from "Get Transactions" with Discover
and Chase credit card accounts.
--
Jerry Jaskierny
___
gnucash-devel mailing
31 matches
Mail list logo
