On Tue, Jul 15, 2008 at 1:23 AM, Nathan Buchanan <[EMAIL PROTECTED]> wrote:
> Hi! > > On Mon, Jul 14, 2008 at 11:33 AM, Charles Day <[EMAIL PROTECTED]> wrote: > >> On Mon, Jul 14, 2008 at 8:07 AM, Stuart D. Gathman <[EMAIL PROTECTED]> >> wrote: >> >> > On Mon, 14 Jul 2008, Martin Preuss wrote: >> > >> > > Though he currently doesn't need to enter dates which are outside the >> > scope of >> > > time_t he is curious about the reason of the limitation to time_t >> instead >> > of >> > > using another, wider type. >> > >> >> Exactly. >> >> >> > > Maybe gnucash lives long enough to exceed the date range offered by >> > time_t and >> > > then the question might arise again :-) >> > >> > Indeed, Dec 18, 2038 is coming fast. >> > >> >> Yes, considering that some folks have mortgage payments spread over 30 >> years, i.e. through 2038. So to some degree, time_t will be obsolete 6 >> months from now. There has been talk of 50 year mortgages in the U.S., and >> these may already be available elsewhere. > > > If I recall correctly, time_t isn't specified to be 32 bit, just that it is > a signed integer. As 64 bit systems become more prevalent, this problem will > go away because time_t will get defined as 64 bits....giving us plenty of > room. > What about my 300 billion year mortgage? > How big of a problem is this in reality? I know of people that have 99 year > leases (though it is admittedly a special case) - they would already have > this problem. > > I guess the real question is - can we wait a couple years for a 64 bit > time_t? Probably, I think. > Yeah, I guess those sticking with a 32-bit time_t will just have to give up some limited functionality until they upgrade. Cheers, Charles Nathan > >> >> >> Why use a time stamp? My companies' accounting system uses a 32-bit day >> no >> > - >> > days since the Jewish/Christian traditional creation in 4012 BC (Julian >> > day). >> > Most accounting computations deal with days between dates (subtract) >> > or day of the week (modulo 7). Functions like "last day of month" are >> > trivial with dayno->mdy and mdy->dayno conversions. Conversion to/from >> > month,day,year is small and simple for Gregorian Calendar (code on >> > request). >> > Other calendars are just as easy and earn Geek points. >> > >> > If there is some module that requires actual timestamps (say pickup and >> > delivery tracking), it can store a wider type, or tack-on a timeofday >> > field. >> > >> >> Time of day is important in some areas, such as price quotes (or at least >> it >> should be), so if there is any change at all then I would think using a >> wider type makes more sense than dropping time of day. >> >> >> > >> > -- >> > 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. >> > _______________________________________________ >> > gnucash-devel mailing list >> > [email protected] >> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > >> >> -Charles >> _______________________________________________ >> gnucash-devel mailing list >> [email protected] >> https://lists.gnucash.org/mailman/listinfo/gnucash-devel >> > > > > -- > <><><><><><><><><><><><><><><> > "Even if you are on the right track, you'll get run over if you just sit > there" - Will Rogers > _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
