On Sat, 18 Jul 2009 17:34:41 +0100, "David Webber"
<dave@musical-dot-demon-dot-co.uk> wrote:
I should also add that the blindingly obvious solution is also the better
one, as CTime is documented as working only for years between 1970 and 3000
:-)
If Joe doesn't like CTime, there is always time.h!
Frankly, the CTime solution is, to my mind, the easiest and avoids
having to know the little ins and outs of the leap year rule to avoid
problems with the year 2000 (if retrospective dates are called for)
and 2100 (if you code will last that long). Joe knows the leap year
rule cold -- many people don't.
I can't imagine anybody doing so many "how many days are there in this
month" calculations to let performance issues be a factor -- the
convenience and performance of the programmer is the real main factor.
So program what you find convenient and easy and know will provide the
correct result!
Ah, but the introduction of a time class (besides adding overhead) also adds all the headaches associated with time zones and DST
switchover dates. David's solution puts the time as mid-day, which puts all the headaches in the Eastern hemisphere.... so maybe
the OP (or David) don't care about time zone and DST adjustments over there. :)
Anyway, why bother to put so much waste into the code when you can simply make a fist and use your knuckles to remember which months