On Sat, Aug 16, 2008 at 6:39 PM, Stuart D. Gathman <[EMAIL PROTECTED]>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 <[EMAIL PROTECTED]> > 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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
