Re: Why C is really a bad programming language

jameskuyper said:

Richard Heathfield wrote:
jameskuyper said:

<snip>

What qualifies as "near that time" depends upon how far into the
future they use time_t. A 30-year mortgage schedule is already in
trouble. Other, shorter-term projections are going to start
running into trouble in the not-to-distant future.

I've worked on many financial services applications, and can attest
to the fact that time_t is /not/ normally used for projections.
Yes, it's used to find "today", so to speak, but then usually the
dates are rolled up "by hand". That's because it's actually easier
that way.

I would actually have expected that it's pretty common to use tools
other than C (like spreadsheets) and operating systems that are not
Unix-like (such as Windows) for such purposes,

Well, Windows has time_t too! :-) But actually you're partly right -
Unix-like systems /are/ used, but not uniquely by any means.
Insurance roll-ups, for example, may well be carried out on IFAs'
laptops (pretty much 100% Windows, although of course there are
always exceptions), or on the corporate mainframe.

However, I'm not at
all clear on what you mean by 'rolled up "by hand"', and therefore
am not clear on why it would be easier that way.

I mean something like (and in reality it's much more involved, but I'm
sticking to the core principle here):

startdate = ToJulian(today);

enddate = startdate + term * DAYS_PER_YEAR;
while(startdate < enddate)
{
do_a_one_day_calc(&stuff);
++startdate;
}

It is not unknown for powers to be used instead:

endamt = startamt * pow(1.0 + i / 100.0, enddate - startdate);

You will only rarely see time_t/struct tm/mktime used to calculate the
end of the term. I am not claiming that this /never/ happens,
however.

Whatever the reason is, the point I was making is more general than
that specific example. Anyone using time_t to work with future times
is going to run into Y2038 problems ahead of "schedule", regardless
of how many people there are who are NOT using time_t for that
purpose.

Very true.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
This line unintentionally left unblank
.

Relevant Pages

  • Re: Why C is really a bad programming language
    ... A 30-year mortgage schedule is already in ... shorter-term projections are going to start running ... into trouble in the not-to-distant future. ... Anyone using time_t to work with future times ...
    (comp.lang.c)
  • Re: Why C is really a bad programming language
    ... A 30-year mortgage schedule is already in ... shorter-term projections are going to start running ... into trouble in the not-to-distant future. ...
    (comp.lang.c)
  • Re: subjunctive mood and Microsoft
    ... Imagine a book laid out on top-posting principles. ... and it gets tedious if they don't snip at all. ... > it is more trouble than it is worth to mark the current ... > message as unread, display all messages, find the unread one, and ...
    (microsoft.public.word.application.errors)
  • Re: KSER Regional Rep (was Re: Even bigger problems at BN ?)
    ... this very newsgroup that BN was in trouble: ... Naturism in the UK [snip] We need a new regime, ... of 2005 saw Bn nearly go bust. ... symptom of a wrong approach than the fundamental problem. ...
    (uk.rec.naturist)
  • Re: Architetural Decisions
    ... > I'm on my way to my first OOP-for-real project in C#, ... > trouble with code architeture. ... telling us about your database structure? ...
    (microsoft.public.dotnet.languages.csharp)