Path: utzoo!utgpu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F. Haugh II)
Newsgroups: alt.sources.d
Subject: Re: Looking for a tool to make UNIX-Time
Message-ID: <18761@rpp386.cactus.org>
Date: 29 Nov 90 16:24:54 GMT
References: <1990Nov29.040427.15103@cerberus.bhpese.oz.au>
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 36
X-Clever-Slogan: Recycle or Die.

In article <1990Nov29.040427.15103@cerberus.bhpese.oz.au> Sm@cerberus.bhpese.oz.au (Scott Merrilees) writes:
>But then you have to know all the garbage about when daylight savings
>time cuts in/out, leap years etc.  This solution is simple, has a
>few guesses, and will work anywhere without telling it extra stuff.
>It may not be terribly efficient, but probably won't be called that
>often.  I like both it, and the side step to think of doing it that
>way.

I'm really sorry that you and Gregory have decided to attack my
suggestion without trying to do anything with it.

The code correctly gets within 48 hours of the day you want,
regardless of leap years, time zones, daylight savings time,
etc.  All that is left is figuring out how many hours off
the guess was.  That is very trivial and only requires one
or two calls to localtime to get.  It is very easy to figure
out the difference between two very close dates, so the hours
fall out very quickly.  Extending to support hours, minutes
and seconds is painless.

Sure, the original posted solution is "correct", but then
so would be starting at 0 and counting up by ones.  Binary
approximation is a very old technique.  It is not new or
clever.  It is a lazy solution to a really simple problem.
Clever would have been binary approximation using whole
hours or days, both of which would have been an improvement
and would have shown some thought.

As for not being called all that often, what if the application
is something like "expire" which must deal with textual dates
in article headers?  Still think it won't be called that often?
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"SCCS, the source motel!  Programs check in and never check out!"
		-- Ken Thompson