time_t

[Charles Day]

On Tue, Jul 15, 2008 at 1:23 AM, Nathan Buchanan <nbinont at gmail.com> wrote:

> 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.
>

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 <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
>