Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!noao!stsci!ansok
From: ansok@stsci.EDU (Gary Ansok)
Newsgroups: comp.lang.c
Subject: Re: need "yy-ddd-hh:mm:ss ==> (time_t) clock" converter
Message-ID: <2323@stsci.EDU>
Date: 11 Feb 91 20:07:38 GMT
References: <TSINGLE.91Jan18120847@sunland.gsfc.nasa.gov> <368@bria> <6586@gssc.UUCP>
Reply-To: ansok@stsci.EDU (Gary Ansok)
Distribution: comp
Organization: TRW, c/o Space Telescope Science Inst., Baltimore, MD
Lines: 32

In article <6586@gssc.UUCP> timr@gssc.UUCP (Tim Roberts) writes:
>> int mdays[12] = { 31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31 };
>
>I have seen this construct in date solutions several times over the past
>two weeks.  In my experience, it is almost always better to use an array of
>the _accumulated_ days through the end of the month, rather than the actual
>days in the month.  This generally lets one eliminate at least one loop.
>
>For example:
>
>int mdays[12] = { 31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365 };

This is likely to go off into a "speed vs. style" war, but I tend to
agree with those who say that unless this is a very time-critical
piece of code (hard to imagine for a date conversion routine, but I
suppose it's possible), the benefits of the first in readability and
maintainability far outweigh any speed gained by the second.

Another suggestion -- depending on how the rest of your code represents
months (and unless you're extremely tight on memory), use
    int mdays[13] = { 0, 31, 28, ...

This makes mdays[1] correspond to January, the way most people expect.
Of course, if January is 0 throughout your code, you may as well be 
consistenly confusing.

Besides, it doesn't necessarily mean another loop to do it this way.
See _The Elements of Programming Style_, pp. 52-54 (by Kernighan and
Plauger).  True, it did add another statement to the body of the loop.

Gary Ansok
ansok@stsci.edu