Maybe the GnuCash manual should stipulate that Gnucash users should never move
east?
David
;)
--- On Tue, 8/19/08, Derek Atkins <[EMAIL PROTECTED]> wrote:
> When you enter a date stamp in the UI, GnuCash chooses
> midnight
> on that day as the timestamp to represent the day. This
> works
> jus
On Tue, Aug 19, 2008 at 10:16 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Mike or Penny Novack <[EMAIL PROTECTED]> writes:
>
> > Please understand that this whole problem about "time" has me very
> confused.
> >
> > I do not understand WHAT time is under discussion. I do not understand
>
Please understand that this whole problem about "time" has me very confused.
I do not understand WHAT time is under discussion. I do not understand
the ("business") meaning of "posting time" as never in accounting have I
come across the time at which the bookkeeper posts a transaction to be
of
Hi,
Mike or Penny Novack <[EMAIL PROTECTED]> writes:
> Please understand that this whole problem about "time" has me very confused.
>
> I do not understand WHAT time is under discussion. I do not understand
> the ("business") meaning of "posting time" as never in accounting have
> I come across t
"Stuart D. Gathman" <[EMAIL PROTECTED]> writes:
> It takes more than a simple patch, but the date bug can be completely
> squashed by simply storing the timezone in the in memory register. It could
> be
> as compact as a time_t plus a 1 byte index into a timezone table. All
> register dates are
On Mon, 18 Aug 2008, Stuart D. Gathman wrote:
> It takes more than a simple patch, but the date bug can be completely
> squashed by simply storing the timezone in the in memory register. It could
> be as compact as a time_t plus a 1 byte index into a timezone table. All
> register dates are disp
On Mon, Aug 18, 2008 at 10:39 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> "Charles Day" <[EMAIL PROTECTED]> writes:
>
> > On Mon, Aug 18, 2008 at 9:53 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> >
> > "Charles Day" <[EMAIL PROTECTED]> writes:
> >
> > > However, the closing transact
On Mon, 18 Aug 2008, Charles Day wrote:
> That means there is no automatic way to tell a book closing transaction from
> a transaction shifted by the bug. So this patch, as is, would screw up
> anyone who has used the book closing feature. Is there anything in the data
> file, perhaps outside of t
"Charles Day" <[EMAIL PROTECTED]> writes:
> On Mon, Aug 18, 2008 at 9:53 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
>
> "Charles Day" <[EMAIL PROTECTED]> writes:
>
> > However, the closing transaction needs to be the "last" transaction
> > of the day.
> >
> > Is th
On Mon, Aug 18, 2008 at 9:53 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> "Charles Day" <[EMAIL PROTECTED]> writes:
>
> > However, the closing transaction needs to be the "last" transaction
> > of the day.
> >
> > Is there any way to tell which transactions were created by book closing?
>
"Charles Day" <[EMAIL PROTECTED]> writes:
> However, the closing transaction needs to be the "last" transaction
> of the day.
>
> Is there any way to tell which transactions were created by book closing? A
> particular description, for example?
Nope. There's currently no tag that a txn i
On Sat, Aug 16, 2008 at 6:39 PM, Stuart D. Gathman <[EMAIL PROTECTED]>wrote:
> On Sat, 16 Aug 2008, Charles Day wrote:
>
> If you want to keep the existing file format unchanged, keep it
>>> unchanged. New programs are free to use the included timezone to
>>> extract the original date - or equiv
On Sat, 16 Aug 2008, Charles Day wrote:
>> If you want to keep the existing file format unchanged, keep it
>> unchanged. New programs are free to use the included timezone to
>> extract the original date - or equivalently, ignore everything except
>> the date. When the timestamps are loaded into
On Sat, Aug 16, 2008 at 8:04 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> "Charles Day" <[EMAIL PROTECTED]> writes:
>
> > How does this patch handle the (non-default) time used in the
> > book closing transactions?
> >
> > I was not aware of this issue. My patch doesn't change the backend
On Fri, Aug 15, 2008 at 4:08 PM, Stuart D. Gathman <[EMAIL PROTECTED]>wrote:
> Charles Day wrote:
>
>
> The problem is that this is an obfuscated flag. If you're going to flag
> dates, flag them with a new XML field. However unlikely, the 00:00:00
> flag will fail, and you have the worst of al
"Charles Day" <[EMAIL PROTECTED]> writes:
> How does this patch handle the (non-default) time used in the
> book closing transactions?
>
> I was not aware of this issue. My patch doesn't change the backend's file
> writing code, so whatever timestamp is assigned by GnuCash is what gets sav
Charles Day wrote:
>
> I was not aware of this issue. My patch doesn't change the backend's file
> writing code, so whatever timestamp is assigned by GnuCash is what gets
> saved. If the time written isn't midnight, the patch will think that the
> transaction is bug-affected when the file is read i
Charles Day wrote:
The problem is that this is an obfuscated flag. If you're going to flag
dates, flag them with a new XML field. However unlikely, the 00:00:00
flag will fail, and you have the worst of all possible situations - code
that fails *rarely*.
If you want to keep the existing f
On Fri, Aug 15, 2008 at 7:46 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Christian Stimming <[EMAIL PROTECTED]> writes:
>
> > Am Donnerstag, 14. August 2008 22:51 schrieb Charles Day:
> >> On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> >> > Previously I proposed an init
On Thu, Aug 14, 2008 at 10:12 PM, Christian Stimming <[EMAIL PROTECTED]>wrote:
> Am Donnerstag, 14. August 2008 22:51 schrieb Charles Day:
> > On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> > > Previously I proposed an initial fix for the "posting time" bug
> (#137017)
>
Christian Stimming <[EMAIL PROTECTED]> writes:
> Am Donnerstag, 14. August 2008 22:51 schrieb Charles Day:
>> On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
>> > Previously I proposed an initial fix for the "posting time" bug (#137017)
>> > that involved no new features and
Am Donnerstag, 14. August 2008 22:51 schrieb Charles Day:
> On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> > Previously I proposed an initial fix for the "posting time" bug (#137017)
> > that involved no new features and use of a fixed time zone of UTC
> > internally. See:
On Wed, Aug 6, 2008 at 9:33 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> Previously I proposed an initial fix for the "posting time" bug (#137017)
> that involved no new features and use of a fixed time zone of UTC
> internally. See:
> https://lists.gnucash.org/pipermail/gnucash-devel/2008-July/02
Previously I proposed an initial fix for the "posting time" bug (#137017)
that involved no new features and use of a fixed time zone of UTC
internally. See:
https://lists.gnucash.org/pipermail/gnucash-devel/2008-July/023613.html
After thinking about this a bit longer, I realized that using UTC int
Am Mittwoch, 23. Juli 2008 20:29 schrieb Charles Day:
> Leaving aside the talk of new features, I would like to propose an initial
> set of changes that will squash the current bug caused by a change to the
> OS timezone without introducing any new features. New features can be added
> later on of
On Wed, Jul 23, 2008 at 11:29 AM, Charles Day <[EMAIL PROTECTED]> wrote:
> Leaving aside the talk of new features, I would like to propose an initial
> set of changes that will squash the current bug caused by a change to the OS
> timezone without introducing any new features. New features can be
Leaving aside the talk of new features, I would like to propose an initial
set of changes that will squash the current bug caused by a change to the OS
timezone without introducing any new features. New features can be added
later on of course.
The goals are:
-Prevent changes to the OS time zone f
27 matches
Mail list logo
