date interval handling is toast
Christian Stimming
stimming@uclink.berkeley.edu
Wed, 21 Mar 2001 12:14:11 -0800
-----BEGIN PGP SIGNED MESSAGE-----
I just figured out why some reports seem to pick the wrong dates when
reporting over several intervals of time. This happens in the
income-expense-graph.scm and the average-balance.scm, but the same
problems might affect the qif importer code as well.
The problem is how we increment a given date, say, by "one week".
Currently we do this (incdate this-date WeekDelta), where WeekDelta
represents the seconds in one week, 3600*7. incdate just adds those second
to the given date. BUT this does not account for daylight saving time!!!!
(Leave alone leap seconds...) And since all dates are in localtime, we
have to take daylight saving time into account! The result is that when
you have the Sept 20, 0:0:0, and you add WeekDelta to it (and the end of
daylight saving time was in that week), you do *not* arrive at Sept 27,
0:0:0, but instead at Sept 26, 23:0:0, which is not what we wanted.
IMHO the only solution to this is to throw out incdate, WeekDelta et al
completely and switch to a fully symbolic solution, i.e. (gnc:incdate
this-date 'week). As an aside, this would also solve the problem with
month increments because each month tends to have a different amount of
seconds in it.
This affects at least the following code:
qif-import/qif-merge-groups.scm:56: query #t (decdate date
WeekDelta) #t (incdate date WeekDelta)
report/average-balance.scm:140: (interval-end (incdate
start-date interval))
report/average-balance.scm:199: (set! interval-end (incdate
interval-start interval))
report/income-expense-graph.scm:149: (dates-list (gnc:dateloop
Christian
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
iQCVAwUBOrkLlGXAi+BfhivFAQFTcQQAh24nRVCC0C2Hrr2z0KHq+EcNNBw/wkCj
jTuNTSNA4mR+rZWINRIFyVjgcdNmVzLStUhthuPdwL/FtGhjoKTMxdV6vtouv+J1
DsCs+sBpATdd7K0LqaeVI+UDYHNtDouAOg1krVSdA9RAx0G3lQBRGImdm85XqeuO
b73fT1iQYOc=
=c+Bm
-----END PGP SIGNATURE-----