Posting time bug fix proposal (simplified)

Charles Day cedayiv at gmail.com
Sat Aug 16 22:48:47 EDT 2008


On Sat, Aug 16, 2008 at 6:39 PM, Stuart D. Gathman <stuart at gathman.org>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 equivalently, ignore everything except
>>> the date.  When the timestamps are loaded into a struct tm or equivalent
>>> - lo and behold, the month,day,year fields have the correct date.
>>>
>>
>>
>> Using the date and dropping the time and time zone only works reliably for
>> transactions that are not already bug-affected. And this is what the patch
>> does. But the rest of the challenge is to detect transactions that have
>> already been thrown off by the bug, then derive the original date entered.
>> The patch is designed to do that too.
>>
>
> As long as the same time zone is always used, existing transactions and
> code are fine.   If some transactions are entered in a different time zone,
> then the new program can easily convert them to a new time zone: just load
> the date, and set the timezone.  Guaranteed to keep the date the same (it
> loses the actual time of the transaction, but that is not shown currently
> anyway).  The only difficulty is that the new program doesn't know which
> time
> zone is the desired one.  *That* could be a config option.  Or a utility
> could count which timezone is most popular among the transactions and use
> that (minimizes changes to the file).  In fact, the whole "change the
> timezone to make the date consistent" thing might be better done as a
> utility - although explaining to an end user what is about to happen
> might be tricky.
>

Ah, I think I see what you are driving at now. I actually had considered
making the file-writing portion of the code use a fixed time zone instead of
the local one, but the only purpose of that is to avoid date shifting when
going back to a previous GnuCash version, and you can't pick one a time zone
that works everywhere. For example, if you write a file using UTC-11 (Samoa)
then open the file with an older version of GnuCash in New Zealand during
daylight savings (UTC+13), every transaction would get shifted forward by a
day due to the 24 hour time difference. If you pick Hawaii (UTC-10) then
everything gets date shifted backwards in Samoa (UTC-11).


>  Instead of doing the mktime() thing and dividing by seconds per day
>>>
>>
>> I'm not following... I don't think I used any division in the patch. Which
>> part of the code are you referring to?
>>
>
> Your patch doesn't, but when calculating days between dates (scheduled
> payments, etc), that is what happens unless you convert to a dayno first.
> An offtopic plug for real dates.
>

Writing a date alone to the file sounds good, but there is a significant
cost: all backward compatability would be lost.


> --
>              Stuart D. Gathman <stuart at bmsi.com>
> Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
> "Confutatis maledictis, flamis acribus addictis" - background song for
> a Microsoft sponsored "Where do you want to go from here?" commercial.
>

-Charles


More information about the gnucash-devel mailing list