Stuart D. Gathman wrote:
ts:date2008-04-10 18:02:00 -0400/ts:date
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
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
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 returns
Am Mittwoch, 16. Juli 2008 22:04 schrieb Charles Day:
OK, here's an idea. I'm interested in seeing the reaction. Maybe it's
stupid, maybe not.
1. Store transaction timestamps in UTC.
Transactions currently store two timestamps, see
http://svn.gnucash.org/docs/HEAD/structtransaction__s.html
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 timezone.
On POSIX systems,
On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan [EMAIL PROTECTED] wrote:
Hi!
On Wed, Jul 16, 2008 at 4:04 PM, Charles Day [EMAIL PROTECTED] wrote:
OK, here's an idea. I'm interested in seeing the reaction. Maybe it's
stupid, maybe not.
I havn't looked at the time code used in gnucash, so
On Thu, Jul 17, 2008 at 1:37 AM, Christian Stimming [EMAIL PROTECTED]
wrote:
Am Mittwoch, 16. Juli 2008 22:04 schrieb Charles Day:
OK, here's an idea. I'm interested in seeing the reaction. Maybe it's
stupid, maybe not.
1. Store transaction timestamps in UTC.
Transactions currently
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
(even a 64 bit one) loses critical info: the
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
For what proprietary accounting products do you get to have a long and
heated argument with the developers about the best way to store dates?
Maybe if you are their biggest customer with a multi-million dollar
contract on the line. I just wanted to take time out from the argument
to say
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 the time of
Charles Day wrote:
On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman [EMAIL PROTECTED]
mailto:[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
On Thu, Jul 17, 2008 at 10:20 AM, Stuart D. Gathman [EMAIL PROTECTED]
wrote:
Charles Day wrote:
On Thu, Jul 17, 2008 at 9:46 AM, Stuart D. Gathman [EMAIL PROTECTED]mailto:
[EMAIL PROTECTED] wrote:
Nathan Buchanan wrote:
I agree that the 00:00 timestamp is a bug, but the 12:00Z or
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 time
On 7/17/08, Charles Day [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan [EMAIL PROTECTED]
wrote:
Hi!
On Wed, Jul 16, 2008 at 4:04 PM, Charles Day [EMAIL PROTECTED] wrote:
OK, here's an idea. I'm interested in seeing the reaction. Maybe it's
stupid, maybe not.
On Thu, Jul 17, 2008 at 11:22 AM, Nathan Buchanan [EMAIL PROTECTED] wrote:
On 7/17/08, Charles Day [EMAIL PROTECTED] wrote:
On Wed, Jul 16, 2008 at 9:07 PM, Nathan Buchanan [EMAIL PROTECTED]
wrote:
Hi!
On Wed, Jul 16, 2008 at 4:04 PM, Charles Day [EMAIL PROTECTED] wrote:
OK, here's an
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 per
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
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 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
20 matches
Mail list logo
