2009-07-01 GnuCash IRC logs

02:36:07 *** puck has quit IRC
02:41:46 *** puck has joined #gnucash
03:02:44 *** kling0n has joined #gnucash
03:14:33 *** bentob0x has joined #gnucash
03:16:15 *** MechtiIde has joined #gnucash
03:17:21 *** ErKa has joined #gnucash
03:46:48 *** ErKa has quit IRC
03:58:47 *** ErKa has joined #gnucash
04:29:05 *** kling0n has quit IRC
05:34:26 *** localhost has quit IRC
05:35:28 *** localhost has joined #gnucash
05:47:37 *** rockfx02 has quit IRC
05:48:02 *** rockfx02 has joined #gnucash
06:03:21 *** Guy- has quit IRC
06:04:11 *** Guy- has joined #gnucash
06:23:55 *** rockfx02 has left #gnucash
06:23:56 *** Rolf2 has left #gnucash
06:50:41 *** Rolf2 has joined #gnucash
06:51:48 <Rolf2> Is there an "easy" way that I can compile gnucash to enter transactions always as midnight UTC, regardless of locale timezone? This nonsense is driving me nuts.
06:51:52 *** Rolf2 is now known as Rolf
06:52:13 <Rolf> Where would I need to look?
07:00:36 <Rolf> Maybe the easiest way is to tweak the gnucash shell script to default to UTC?
07:07:34 *** warlord-afk is now known as warlord
07:07:59 <warlord> Rolf: that might work... But you'd have to worry about existing txns too..
07:08:13 <Rolf> yes
07:08:22 <Rolf> I'll update them with an SQL statement
07:08:35 <Rolf> Unfortunately, not the first time I had to fix stuff manually in the db
07:09:07 <Rolf> I'm looking into src/bin/ now, but I'm not 100% sure how the shell script is created after all
07:09:11 <Rolf> Hints?
07:09:21 <Rolf> src/bin/generate-gnc-script?
07:09:58 <Rolf> doesn't seem to have all that I have in my current gnucash script
07:10:41 <Rolf> But maybe a few things were dropped. I'm rebuilding from trunk and take another look
07:12:21 <warlord> On windows I think it's created by the installer.
07:16:37 <warlord> Honestly I dont think that's the best long-term solution.
07:16:53 <warlord> (changing the locale in the startup script)
07:25:02 <Rolf> sure it's not the best long-term solution
07:25:13 <Rolf> But given the fact there's not been a solution for years
07:25:29 <Rolf> and that including timezone data for post_date is ludicrous
07:25:44 <Rolf> given that, I think it's a workable solution for me for the moment
07:32:26 *** Jimraehl has quit IRC
07:35:37 *** ErKa has quit IRC
07:39:59 <warlord> Yes, including TZ data for post_date is ludicrous. I dont know why that was done.
07:40:30 <Rolf> warlord: Is it correct that post_date which AFAICT corresponds with xaccTransRetDatePostedTS is the date a transaction was entered and enter_date AKA xaccTransRetDateEnteredTS is the date the transaction took place?
07:40:44 <warlord> No.
07:40:48 <Rolf> Looks kind of backwards to me in the way the variables where named
07:41:04 <warlord> Date Entered is the timestamp that you enter the txn into gnucash.
07:41:17 <warlord> Date Posted is the date that you see in register
07:41:39 <Rolf> That is what I would expect
07:41:52 <Rolf> But at least in sqlite it seems to be the other way rouns
07:42:07 <Rolf> 09365e723002c3d8fb52e69809f754d9|c5d42961f3ad45193344924a89d8a2cb||20080325230000|20090701000803|Jahresvertrag 2008
07:42:11 <Rolf> live example
07:42:42 <Rolf> 20080325230000 is enter_date and 20090701000803 is post_date
07:42:45 <warlord> I have no idea what the columns mean...
07:42:48 <Rolf> AFAICT
07:42:52 <warlord> And if there's an issue you should talk to Phil.
07:43:12 <warlord> Maybe he mis-named the columns.
07:43:15 <Rolf> Let's talk about the xacc things, then
07:44:00 <warlord> I also notice there are no TZ in the SQL
07:44:09 <Rolf> alright, I'll open a bug report to see if this is a valid issue or if I am just doing something wrong
07:44:19 <Rolf> warlord: sure there are
07:44:31 <Rolf> 20080325230000 should be one hour later
07:44:51 <Rolf> because the transaction took place on the 26th
07:45:20 <Rolf> It'c completely unusable without tweaking
07:45:42 <Rolf> I have a very long and complicated SQL statement to do that for me
07:45:44 <warlord> Rolf: You're not listening.. There is no TZ DATA in the SQL. I have no idea what TZ "20090701000803" is supposed to be in.. That's DEFINITELY an issue.
07:46:07 <warlord> The date should be a UTC timestamp..
07:46:09 <warlord> (and used as such)
07:46:13 <Rolf> Oh, sorry I missed your drift (although I *was* listening, OK?)
07:47:13 <warlord> IMHO, all data should be used and stored as UTC. The only time we should use 'localtime' is to compute the "current local date" when we open a register.
07:49:09 <warlord> The hard problem is auto-converting existing data files.
07:50:57 <Rolf> I agree with you
07:51:53 <Rolf> I'm not sure what is hard about converting the existing files, though
07:52:20 <Rolf> It should be possible to deduce the timezone originally used from the timestamp
07:53:05 <Rolf> Actually, no I don't agree with you
07:53:30 <warlord> it wont detect screwed-up data files.. Keep in mind that the TZ gets re-adjusted every time you re-save the XML, so if you moved TZs then you'll have data with different offsets.
07:53:37 <Rolf> post_date (the date the tx took place) should have no tz information at all
07:53:44 <Rolf> It is simply a date and that is it
07:54:06 <warlord> Nope, you need additional information to deal with things like Periods and "closing transactions".
07:54:14 <Rolf> I know, I do have at least four different timezones in my data now
07:54:23 <Rolf> 2200 gets +2hours
07:54:27 <warlord> So, "just a date" doesn't suffice.
07:54:31 <Rolf> 2300 gets +1hour, etc.
07:55:08 <Rolf> I'm sorry but I don't buy that
07:56:04 <Rolf> It makes no difference if I bought something 5 minutes before midnight on Dec 31st local time
07:56:21 <Rolf> It still is a tx for Dec 31st a couple of TZ east of here
07:56:36 <Rolf> anything else will keep gnucash in a broken state
07:57:22 <Rolf> If GC looks at anything finer than date for closing periods etc. it's broken
07:57:25 <warlord> Rolf: it makes a difference for reports!
07:57:32 <warlord> Bullshit.
07:57:33 <Rolf> well, it should not
07:57:49 <Rolf> alright, if you want to use strong words, I can too
07:57:54 <warlord> How do I have a 'closing transaction' that doesn't get included in report?
07:57:55 <warlord> s
07:58:26 <warlord> The only way to do that is to make sure that the transaction falls after the ending date of the previous period, and before the begin-date of the next.
07:58:37 <Rolf> I don't know and I don't care. But if my TX for Dec31 turns up on Jan 1st in another timezone that is nonsense.
07:58:47 <warlord> If all transactions only have dates, you cannot represent e.g. "December 32nd"
07:58:56 <Rolf> IOW, the hour information is not needed
07:59:01 <warlord> And the fact that you don't care is exactly the problem
07:59:10 <warlord> If you don't care then shut up and let us solve the problem.
07:59:16 <Rolf> Tell me why it SHUOLD matter
07:59:21 <warlord> I just did
07:59:47 <Rolf> And I told you that a Dec31st TX remains that whereever you are
07:59:47 <warlord> When you close the books and zeroize your income/expense accounts, you do not want to include that zeroing transaction in reports.
07:59:58 *** JimRaehl2 has joined #gnucash
08:00:16 <warlord> But a CLOSING TRANSACTIOn is outside the period.
08:00:26 <warlord> Its lives "between periods"
08:00:33 <warlord> So you need a way to represent that.
08:00:49 <Rolf> and you do that with a split second kind of trick?
08:00:55 <warlord> Yes
08:01:34 <Rolf> alright
08:02:33 <warlord> So if I want to report on 1 Jan 2008 - 31 Dec 2008 I would report on 20080101000000-20081231000000.
08:03:21 <Rolf> not sure how other accounting packages deal with this, but I maintain that hourly information for a TX is nonsense (especially since GC does not record at what hour a TX really took place, it just assumes midnight local time). You are entitled to your position.
08:03:21 <Rolf> I will just say that this "we need hourly information" creates a shitload of problems
08:03:35 <warlord> Now I can put a closing transaction at, say, 20081231010000 and it wont show up in reports, because for 2009 I'd go: 20090101000000-20091231000000. The closing txn wont show up, which is exactly what we want.
08:04:13 <warlord> I'm not saying we need hourly information. I'm saying that "just storing a date" is insufficient.
08:04:39 <Rolf> alright, then what IS necessary on top of date IYO?
08:04:49 <warlord> Are you reading what I'm saying?
08:05:02 <warlord> We need to be able to say that a transaction happens "between dates"
08:05:11 <Rolf> Then add a field
08:05:15 <Rolf> for example
08:05:23 <Rolf> binary
08:05:36 <Rolf> using hourly information for that is hackish and nonsense
08:05:43 <Rolf> and that is not bullshit
08:05:46 <warlord> That would require a change to every query.
08:05:51 <Rolf> however strong words you like to use
08:05:54 <Rolf> so?
08:06:00 <Rolf> Their broken
08:06:05 <warlord> Fine.. YOU go through the code and fix EVERY query.
08:06:25 <Rolf> You were accusing me of making BS statements
08:06:27 <Rolf> OK?
08:06:30 <warlord> using the date this way may be "hackish", but it solves the problem cleanly without requiring a rototill of the code.
08:06:36 <Rolf> cleanly?
08:06:39 <Rolf> HAHAHAHA
08:06:44 <warlord> It's quite clean.
08:06:54 <Rolf> well, the code may be
08:06:57 <warlord> yep
08:07:03 <Rolf> The output is nonsense
08:07:10 <warlord> And the user interface is clean.
08:07:18 <Rolf> broken beyond ordinary people's skill to fix
08:07:56 <warlord> If all posted dates from user input are of the form YYYYMMDD000000 then how is it "broken beyond ordinary people's skill to fix"?
08:08:00 <Rolf> alright, we have clean code and a clean interface. Sorry, the data we report can not be relied upon. We may fix it in 20+ years.
08:08:03 <Rolf> Serious?
08:08:36 <Rolf> YYYYMMDD000000 is not what it is
08:08:46 <Rolf> You said you want UTC
08:08:47 <warlord> You seem to be all knowing and all seeing, yes, serious, if all posted_date entries from user input is stored as YYYYMMDD000000 then how is it a problem?
08:09:00 <Rolf> If it were, I'd be happy
08:09:02 <warlord> Yep. It's a UTC timestamp.
08:09:06 <Rolf> That is not what you were suggesting
08:09:15 <warlord> Yes it is.
08:09:25 <Rolf> WELL...
08:09:31 <warlord> (if you think otherwise then you're still not listening to me)
08:09:51 <Rolf> You were talking about format and not content? I understood UTC timestamp as "time stored in UTC"
08:09:54 <Rolf> that is not the same
08:10:27 <Rolf> you're still not listening to me -> it takes two for successful communication
08:10:29 <warlord> both XML and SQL use iso8601
08:10:31 <Rolf> and two to fail, too
08:10:40 <warlord> Actually it only takes 1 to fail ;)
08:11:00 <warlord> 1) all timestamps are stored in UTC
08:11:03 <Rolf> alright, then that is you ;-)
08:11:15 <warlord> 2) all date_posted should be midnight at the date in question (UTC)
08:11:22 <warlord> Nope, by definition I am always right ;)
08:11:30 <warlord> So it must be you :-P
08:11:46 <Rolf> that would be funny if it wasn't the attitude you actually display
08:12:29 <Rolf> I just wish somebody would program a sane FOSS accounting package
08:12:40 <warlord> Go ahead!
08:13:46 <warlord> You know, Rolf, you've pissed me off sufficiently in the past that I've almost completely left this project due specifically to you.. Others have talked me down and convinced me to stay.
08:14:05 <warlord> I agree completely that there are problems here.
08:14:31 <warlord> But I actually care about solving them in an extensive way, not just the simplistic bandaid you seem to want to put on.
08:14:50 <warlord> There are more issues at hand than just "we only need a date here" and that tz shift causes date shift..
08:15:04 <warlord> Yes, that's definitely an issue, but it's not the ONLY thing that needs to be considered when coming up with a solution.
08:15:21 <warlord> And the fact that you refuse to understand that pisses me off to no end because you refuse to listen.
08:16:27 <Rolf> I can do the same as you: Are you reading what I wrote?
08:16:27 <Rolf> I never once suggested my bandaid (which at least gets me working again) should be applied in svn. I don't think it's suitable, it still is very valuable to me.
08:16:53 <Rolf> Maybe you need to start to listen?
08:17:02 <Rolf> Again, it takes two
08:17:08 <Rolf> But since you are always right
08:17:33 <Rolf> and that is one very important aspect of what I mean by sane
08:22:06 *** ErKa has joined #gnucash
08:35:49 *** bentob0x has quit IRC
08:37:01 *** bentob0x has joined #gnucash
08:43:03 *** bentob0x has quit IRC
08:44:30 *** bentob0x has joined #gnucash
08:49:30 *** bentob0x has quit IRC
08:50:27 *** bentob0x has joined #gnucash
08:55:57 *** bentob0x has quit IRC
08:56:44 *** bentob0x has joined #gnucash
09:01:44 *** JimRaehl2 has quit IRC
09:03:47 *** bentob0x has quit IRC
09:06:58 *** bentob0x has joined #gnucash
09:10:59 *** bentob0x has quit IRC
09:12:27 *** bentob0x has joined #gnucash
09:20:01 *** lobsang has quit IRC
09:24:26 *** lobsang has joined #gnucash
09:38:21 *** srm has joined #gnucash
09:39:52 <srm> Hi room. What is the explanation for not using the DATE(TIME) type on columns that should contain dates, like TRANSACTIONS.POST_DATE ?
09:45:17 *** JimRaehl2 has joined #gnucash
09:46:36 <warlord> srm: you'll have to ask Phil. He's not here.
09:46:51 <warlord> (I suspect the answer is that DBI doesn't support them, but I dont know if that's true)
09:47:37 <srm> DateTime::Format::DB :)
09:47:46 <srm> s/DB/DBI
09:47:51 <srm> ok, I'll wait then.
09:49:00 <jsled> actually, phil doesn't come round here much. you'll do better asking on the gnucash-devel mailing list.
09:49:13 <srm> I see.
09:50:11 <warlord> srm: I have no idea how that perl module relates to libdbi
09:51:43 <srm> warlord: then "libdbi version 0.8.2 adds support for timezones in TIME and DATETIME types"
09:52:04 <jsled> and http://libdbi.sourceforge.net/docs/programmers-guide/reference-field.html#DBI-RESULT-GET-DATETIME
09:52:23 <warlord> Then I have no idea why he's not using it. You'll have to ask him.
09:52:32 <warlord> (I've tried to convince him to hang out here more often, to no avail)
10:04:06 *** KaiForce has joined #gnucash
10:11:54 *** KaiForce has quit IRC
10:32:16 *** ErKa has quit IRC
10:39:17 *** srm has left #gnucash
11:12:45 *** ErKa has joined #gnucash
11:33:58 *** goodger has quit IRC
12:11:47 *** goodger has joined #gnucash
12:41:26 *** MechtiIde has quit IRC
12:50:09 *** Def has quit IRC
12:53:05 *** Def has joined #gnucash
13:33:43 *** ErKa has quit IRC
13:35:37 *** hvx has joined #gnucash
13:53:37 *** MechtiIde has joined #gnucash
14:00:39 *** linas has quit IRC
14:03:06 *** palatin has joined #gnucash
15:06:49 *** twunder has joined #gnucash
15:13:09 *** linas has joined #gnucash
15:52:27 <warlord> @op linas
15:52:28 *** gncbot sets mode: +o linas
16:02:58 *** goodger has quit IRC
16:06:38 *** palatin has quit IRC
16:19:12 *** hvx has quit IRC
16:32:11 *** bentob0x has quit IRC
16:55:14 *** goodger has joined #gnucash
16:56:52 *** twunder has quit IRC
16:58:25 *** goodger has quit IRC
17:06:12 *** leitz has joined #gnucash
17:06:20 <leitz> ping jsled
17:06:31 <jsled> leitz: yes?
17:07:01 <leitz> FYI, on the "Enter"/enter issue, I updated earlier and am about to update again. Found a workaround.
17:07:47 <leitz> Just entered a couple dozen transactions, only using the enter key, not the "Enter" button.
17:07:51 <leitz> Worked nicely.
17:10:29 <leitz> Bug 586896.
17:12:36 <leitz> Just adding some bright spot to the day. Thanks!
17:12:43 *** leitz has quit IRC
17:14:04 *** goodger has joined #gnucash
18:14:22 *** kling0n has joined #gnucash
18:33:21 *** MechtiIde has quit IRC
18:39:39 *** goodger_ has joined #gnucash
18:48:26 *** goodger has quit IRC
18:49:50 *** goodger_ is now known as goodger
18:51:30 *** goodger_ has joined #gnucash
19:00:12 *** goodger has quit IRC
19:44:48 *** goodger__ has joined #gnucash
19:53:58 *** goodger_ has quit IRC
19:58:03 *** kling0n has quit IRC
20:00:56 *** warlord is now known as warlord-afk
20:46:48 *** goodger_ has joined #gnucash
20:55:35 *** goodger__ has quit IRC
21:49:42 *** JimRaehl2 has left #gnucash
21:55:40 *** Jimraehl has joined #gnucash
23:28:54 *** Rolf1 has joined #gnucash
23:37:12 *** Rolf has quit IRC