time_t

[Nathan Buchanan]

Hi!

On Mon, Jul 14, 2008 at 11:33 AM, Charles Day <cedayiv at gmail.com> wrote:

> On Mon, Jul 14, 2008 at 8:07 AM, Stuart D. Gathman <stuart at gathman.org>
> 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 <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.
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> >
>
> -Charles
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at 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