Seriously? They don't care about their library working on anything
other than FreeBSD?
-derek
John Ralls writes:
> I filed a bug against libdbi for their use of time_t (which is 32-bit
> most everywhere for POSIX compliance):
> https://sourceforge.net/p/libdbi/bugs/15/
>
>
I filed a bug against libdbi for their use of time_t (which is 32-bit most
everywhere for POSIX compliance): https://sourceforge.net/p/libdbi/bugs/15/
They just closed it as "won't fix", saying that FreeBSD has 64-bit time_t so I
should just use that.
I was thinking of looki
On Mon, Dec 3, 2012 at 4:50 AM, John Ralls wrote:
>
> On Dec 2, 2012, at 5:11 PM, Derek Atkins wrote:
>
>>
>> On Sun, December 2, 2012 7:56 pm, Alex Aycinena wrote:
>> [snip]
> /home/gnucash-dev/svncheckouts/gnucash-clean/src/gnome/assistant-acct-period.c:
> In function 'ap_assistant_menu
On Dec 2, 2012, at 5:11 PM, Derek Atkins wrote:
>
> On Sun, December 2, 2012 7:56 pm, Alex Aycinena wrote:
> [snip]
/home/gnucash-dev/svncheckouts/gnucash-clean/src/gnome/assistant-acct-period.c:
In function 'ap_assistant_menu_prepare':
/home/gnucash-dev/svncheckouts/gnucash-clea
On Sun, December 2, 2012 7:56 pm, Alex Aycinena wrote:
[snip]
>>> /home/gnucash-dev/svncheckouts/gnucash-clean/src/gnome/assistant-acct-period.c:
>>> In function 'ap_assistant_menu_prepare':
>>> /home/gnucash-dev/svncheckouts/gnucash-clean/src/gnome/assistant-acct-period.c:309:5:
>>> error: format
gt;>>>
>>>>> Modified:
>>>>> gnucash/trunk/src/optional/gtkmm/gncmm/Transaction.hpp
>>>>> gnucash/trunk/src/plugins/bi_import/dialog-bi-import.c
>>>>> Log:
>>>>> Convert all time_t to time64: optional & plugin
gt; Author: jralls
>>>> Date: 2012-12-01 17:46:08 -0500 (Sat, 01 Dec 2012)
>>>> New Revision: 22628
>>>> Trac: http://svn.gnucash.org/trac/changeset/22628
>>>>
>>>> Modified:
>>>> gnucash/trunk/src/optional/gtkmm/gncmm/Transac
2012)
>>> New Revision: 22628
>>> Trac: http://svn.gnucash.org/trac/changeset/22628
>>>
>>> Modified:
>>> gnucash/trunk/src/optional/gtkmm/gncmm/Transaction.hpp
>>> gnucash/trunk/src/plugins/bi_import/dialog-bi-import.c
>>> Log:
>>>
628
>>
>> Modified:
>> gnucash/trunk/src/optional/gtkmm/gncmm/Transaction.hpp
>> gnucash/trunk/src/plugins/bi_import/dialog-bi-import.c
>> Log:
>> Convert all time_t to time64: optional & plugins
>>
>> __
gt;gnucash/trunk/src/plugins/bi_import/dialog-bi-import.c
> Log:
> Convert all time_t to time64: optional & plugins
>
> ___
> gnucash-patches mailing list
> gnucash-patc...@gnucash.org
> https://lists.gnucash.org/mailman/lis
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?
>
Timestamp (time_t) plus time zone where timestamp was entered is
sufficient to recover the date.
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
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
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.
Stuart,
I'm curious though
As a retired pro who has debugged many date errors in my day I really
have to side with Stuart here.
Michael D Novack, FLMI
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
I've read most but not all of the many messages in the two threads on this
topic. It is clear that there is a lot of passion around the issue.
>From my (end-user) perspective, I agree with (I think) Graham that the
>transaction date that displays in the register should be a date-only entry. I
>
Charles Day wrote:
>
> No, the transaction timestamp is stored, denoting the precise point in
> time at which the transaction posted. The time zone is only needed
> when converting to a date or time of day, and for that you have the
> user's preferences (a default display time zone, a time zone
On Thu, Jul 17, 2008 at 11:10 AM, Stuart D. Gathman <[EMAIL PROTECTED]>
wrote:
> Charles Day wrote:
>
>> The basic idea is that in an account register the user enters a date and
>> time of day (or accepts the default time of day) in terms of that account's
>> timezone. When you view that transact
Charles Day wrote:
> The basic idea is that in an account register the user enters a date
> and time of day (or accepts the default time of day) in terms of that
> account's timezone. When you view that transaction in another
> register that has been set to a different timezone, the date and ti
e. Now imagine trying to support multiple currencies without
> actually storing the currency with the amounts. :-)
>
> As I understand your proposal, it would use localtime "as if" it were GMT
> time. I.e., take the local time, replace the timezone with GMT, and convert
&g
y fine as long as you only ever use one currency. This would be
fine for almost all US users, for instance. Now imagine trying to
support multiple currencies without actually storing the currency with
the amounts. :-)
As I understand your proposal, it would use localtime "as if" it w
On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman <[EMAIL PROTECTED]>
wrote:
> Nathan Buchanan wrote:
> > I agree that the 00:00 timestamp is a bug, but the 12:00Z or 10:01:00Z
> > simply works around the bug for 90% of the use cases. From the
> perspective
> >
> Not only that, but if you force t
Nathan Buchanan wrote:
> I agree that the 00:00 timestamp is a bug, but the 12:00Z or 10:01:00Z
> simply works around the bug for 90% of the use cases. From the perspective
>
Not only that, but if you force the time of day in each timestamp to
12:00Z, then you no longer have a timestamp, but a
Glen Ditchfield wrote:
> Stuart D. Gathman wrote:
>
>
>> The issue here isn't the data file (which I assumed we all agreed
>> included the needed info). The issue is that loading the
>> nice ascii timestamp with timezone into just a time_t field in memory
>&
Stuart D. Gathman wrote:
> The issue here isn't the data file (which I assumed we all agreed
> included the needed info). The issue is that loading the
> nice ascii timestamp with timezone into just a time_t field in memory
> (even a 64 bit one) loses critical info: the ti
Am Dienstag, 15. Juli 2008 21:35 schrieb Derek Atkins:
> Quoting Graham Leggett <[EMAIL PROTECTED]>:
> > If I don't do this, transactions report themselves as being one day
> > early, so transactions on the first of the month suddenly appear on
> > the last day of last month, which sends my VAT ret
Derek Atkins wrote:
Try the string "2008-04-11 00:02:00 +0200". Same timestamp. Different
date.
* sigh *
Are you intentionally ignoring my repeated statement that we need
to CHANGE GNUCASH TO USE 1200Z?
No, read back what you said, which was "For example, what's
the difference between "2008
Stuart D. Gathman wrote:
2008-04-10 18:02:00 -0400
The issue here isn't the data file (which I assumed we all agreed
included the needed info). The issue is that loading the
nice ascii timestamp with timezone into just a time_t field in memory
(even a 64 bit one) loses critical
Hi,
On Mittwoch, 16. Juli 2008, Charles Day wrote:
> On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> > Mike or Penny Novack <[EMAIL PROTECTED]> writes:
[...]
> I agree, 1200UTC would prevent time zones from shifting transactions to
> another day. That would be a better d
On Wed, Jul 16, 2008 at 7:24 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Quoting Charles Day <[EMAIL PROTECTED]>:
>
> > On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> > [snip]
> >
> >>
> >> Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
> >>
On Wed, Jul 16, 2008 at 4:24 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Quoting Charles Day <[EMAIL PROTECTED]>:
>
> On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
>> [snip]
>>
>>
>>> Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
>>> to figu
On Wed, Jul 16, 2008 at 4:24 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Quoting Charles Day <[EMAIL PROTECTED]>:
>
> On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
>> [snip]
>>
>>
>>> Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
>>> to figu
Quoting Charles Day <[EMAIL PROTECTED]>:
> On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> [snip]
>
>>
>> Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
>> to figure out the date from 1200 UTC. However as I've said now three
>> times, GnuCash
Quoting Graham Leggett <[EMAIL PROTECTED]>:
> Try the string "2008-04-11 00:02:00 +0200". Same timestamp. Different date.
* sigh *
Are you intentionally ignoring my repeated statement that we need
to CHANGE GNUCASH TO USE 1200Z? Let's try this example again with
that, and maybe we'll stop talk
Derek Atkins wrote:
This is where the "implicit TZ" comes in. For example, what's
the difference between "2008-04-10 18:02:00 -0400" and
"2008-04-10 15:02:00 -0700"? I would argue that there *is* no
difference. Both timestamps are talking about the exact same time.
And hey look, they both sa
On Wed, Jul 16, 2008 at 2:17 PM, Derek Atkins <[EMAIL PROTECTED]> wrote:
[snip]
>
> Actually, except for GMT-12 or GMT+12, no, you do NOT need the time zone
> to figure out the date from 1200 UTC. However as I've said now three
> times, GnuCash doesn't use 1200 UTC currently, it uses local,
issue here isn't the data file (which I assumed we all agreed
> included the needed info). The issue is that loading the
> nice ascii timestamp with timezone into just a time_t field in memory
> (even a 64 bit one) loses critical info: the timezone.
This is where the "implicit TZ&
ue is that loading the
nice ascii timestamp with timezone into just a time_t field in memory
(even a 64 bit one) loses critical info: the timezone.
--
Stuart D. Gathman <[EMAIL PROTECTED]>
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutat
Quoting "Stuart D. Gathman" <[EMAIL PROTECTED]>:
>>> I agree, 1200UTC would prevent time zones from shifting transactions to
>>> another day. That would be a better default than local. That
>>> could work
>>> for default price times as well (see but 541970).
>
> Storing timestamps for dates
On Wed, 16 Jul 2008, Phil Longstaff wrote:
It is actually the case that (depending on financial policies) storing
the actual time could present problems.
I've had to deal with many such problems in a commercial system using
timestamps for dates. I ended up creating an XLNDate type to c
Derek Atkins wrote:
Yes, but how would you like it if we forced the issue and the way
GnuCash did it was NOT the way you needed it done? Wouldn't you
prefer to be able to set it up for your particular locale in the
way YOU need it to be done?
I've worked in finance for a long time (first insu
Quoting Graham Leggett <[EMAIL PROTECTED]>:
> Derek Atkins wrote:
>
>> These rules can certainly vary from place to place, locale to locale,
>> or even person to person. Why force the issue?
>
> Because the consequences can be expensive.
Yes, but how would you like it if we forced the issue and
Derek Atkins wrote:
These rules can certainly vary from place to place, locale to locale,
or even person to person. Why force the issue?
Because the consequences can be expensive.
I was lucky in that I found and located the source of the problem
relatively quickly. Had I not found it, I wo
On Wed, Jul 16, 2008 at 10:59 AM, Phil Longstaff <[EMAIL PROTECTED]>
wrote:
> Charles Day wrote:
> > On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> >
> >> Mike or Penny Novack <[EMAIL PROTECTED]> writes:
> >>
> >>> I would pay close attention to what Graham says here.
>
Charles Day wrote:
> On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
>
>> Mike or Penny Novack <[EMAIL PROTECTED]> writes:
>>
>>> I would pay close attention to what Graham says here.
>>>
I didn't say that *all* timestamps were unnecessary, what I said was
that d
On Wed, Jul 16, 2008 at 10:38 AM, Charles Day <[EMAIL PROTECTED]> wrote:
>
>
> On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
>
>> Mike or Penny Novack <[EMAIL PROTECTED]> writes:
>>
>> > I would pay close attention to what Graham says here.
>> >
>> >> I didn't say that *
On Wed, Jul 16, 2008 at 9:47 AM, Derek Atkins <[EMAIL PROTECTED]> wrote:
> Mike or Penny Novack <[EMAIL PROTECTED]> writes:
>
> > I would pay close attention to what Graham says here.
> >
> >> I didn't say that *all* timestamps were unnecessary, what I said was
> >> that dates that are actually da
Mike or Penny Novack <[EMAIL PROTECTED]> writes:
> I would pay close attention to what Graham says here.
>
>> I didn't say that *all* timestamps were unnecessary, what I said was
>> that dates that are actually dates, and not times, are being stored
>> as times, and that this is incorrect.
>>
>> F
I would pay close attention to what Graham says here.
> I didn't say that *all* timestamps were unnecessary, what I said was
> that dates that are actually dates, and not times, are being stored as
> times, and that this is incorrect.
>
> For an example, look at the date entered in a transaction
Derek Atkins wrote:
I think this is being caused by dates that are actually dates and not
times, being stores as times.
You think incorrectly.
There are LOTS of reasons to store times in transactions. There ARE
timestamps in the real world. And there are reasons that some people
want to act
Hi,
Quoting Graham Leggett <[EMAIL PROTECTED]>:
> Derek Atkins wrote:
>
>>> Different database engines have different column types for storing
>>> dates/times, so I'm using a 'MMDDHHMMSS' char string.
>>
>> ... in what timezone?Do you always convert to UTC?
>
> The current XML file doesn'
Derek Atkins wrote:
Different database engines have different column types for storing
dates/times, so I'm using a 'MMDDHHMMSS' char string.
... in what timezone?Do you always convert to UTC?
The current XML file doesn't convert to UTC, and as a result my computer
is stuck in the UT
On Tue, Jul 15, 2008 at 2:30 PM, Nathan Buchanan <[EMAIL PROTECTED]> wrote:
>
> On Tue, Jul 15, 2008 at 1:43 PM, Phil Longstaff <[EMAIL PROTECTED]>
> wrote:
>
>> Derek Atkins wrote:
>> > Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>> >
>> >> Different database engines have different column types f
On Tue, Jul 15, 2008 at 1:43 PM, Phil Longstaff <[EMAIL PROTECTED]>
wrote:
> Derek Atkins wrote:
> > Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> >
> >> Different database engines have different column types for storing
> >> dates/times, so I'm using a 'MMDDHHMMSS' char string.
> >
> > ... in
Derek Atkins wrote:
> Quoting Phil Longstaff <[EMAIL PROTECTED]>:
>
>> Different database engines have different column types for storing
>> dates/times, so I'm using a 'MMDDHHMMSS' char string.
>
> ... in what timezone?Do you always convert to UTC?
>
>> Phil
>
> -derek
>
... converte
>> 32 bit system(?) (or processor?) you may still get a 32 bit time_t.
>> You're right - the 64 bit RHEL5 system showed sizeof(time_t) to be 8,
>> while Leopard on my Powerbook G4 said 4, as did RHEL4/i386.
>>
>> Looking at what APR (the Apache portable runtime) d
Quoting Phil Longstaff <[EMAIL PROTECTED]>:
> Different database engines have different column types for storing
> dates/times, so I'm using a 'MMDDHHMMSS' char string.
... in what timezone?Do you always convert to UTC?
> Phil
-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT M
Graham Leggett <[EMAIL PROTECTED]> writes:
> Nathan Buchanan wrote:
>
>> I'm a bit out of my league here...but I believe a long (or long int)
>> is defined to be a minimum of 32 bits - so if you're still using a
>> 32 bit system(?) (or processor?) you m
t;
>> > On Mon, 14 Jul 2008, Martin Preuss wrote:
>> >
>> > > Though he currently doesn't need to enter dates which are outside the
>> > scope of
>> > > time_t he is curious about the reason of the limitation to time_t
>> instead
>> &
Nathan Buchanan wrote:
I'm a bit out of my league here...but I believe a long (or long int) is
defined to be a minimum of 32 bits - so if you're still using a 32 bit
system(?) (or processor?) you may still get a 32 bit time_t.
You're right - the 64 bit RHEL5 system showed si
On Tue, Jul 15, 2008 at 5:25 AM, Graham Leggett <[EMAIL PROTECTED]> wrote:
> Nathan Buchanan wrote:
>
> I guess the real question is - can we wait a couple years for a 64 bit
>> time_t? Probably, I think.
>>
>
> Are there any systems in wide use that aren'
Nathan Buchanan wrote:
I guess the real question is - can we wait a couple years for a 64 bit
time_t? Probably, I think.
Are there any systems in wide use that aren't yet 64 bit time_t? I was
under the impression that OSes had already changed.
A quick look under MacOSX Leopard shows t
to enter dates which are outside the
> > scope of
> > > time_t he is curious about the reason of the limitation to time_t
> instead
> > of
> > > using another, wider type.
> >
>
> Exactly.
>
>
> > > Maybe gnucash lives long enough to e
On Mon, 14 Jul 2008, Charles Day wrote:
> Yes, considering that some folks have mortgage payments spread over 30
> years, i.e. through 2038. So to some degree, time_t will be obsolete 6
> months from now. There has been talk of 50 year mortgages in the U.S., and
> these may already
On Mon, Jul 14, 2008 at 8:07 AM, Stuart D. Gathman <[EMAIL PROTECTED]>
wrote:
> On Mon, 14 Jul 2008, Martin Preuss wrote:
>
> > Though he currently doesn't need to enter dates which are outside the
> scope of
> > time_t he is curious about the reason of the l
On Mon, 14 Jul 2008, Martin Preuss wrote:
> Though he currently doesn't need to enter dates which are outside the scope of
> time_t he is curious about the reason of the limitation to time_t instead of
> using another, wider type.
>
> Maybe gnucash lives long enough to e
Hi,
On Montag, 14. Juli 2008, Derek Atkins wrote:
> Quoting Charles Day <[EMAIL PROTECTED]>:
> > This may be a silly question, but why is GnuCash limited to using dates
> > that are supported by time_t? Could we get rid of time_t?
> >
> > I don't need to ent
Quoting Charles Day <[EMAIL PROTECTED]>:
> This may be a silly question, but why is GnuCash limited to using dates that
> are supported by time_t? Could we get rid of time_t?
>
> I don't need to enter 18th century transactions; I'm just curious.
time_t is #seconds s
This may be a silly question, but why is GnuCash limited to using dates that
are supported by time_t? Could we get rid of time_t?
I don't need to enter 18th century transactions; I'm just curious.
Cheers,
Charles
___
gnucash-devel mailing li
70 matches
Mail list logo
