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. 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. 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 > > gnucash-devel@gnucash.org > > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > > > > -Charles > _______________________________________________ > gnucash-devel mailing list > gnucash-devel@gnucash.org > 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 gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
