[7453] in SIPB bug reports

home help back first fref pref prev next nref lref last post

Re: NEW PROJECT: sunrise/sunset, OR y2k problem in sipb locker

daemon@ATHENA.MIT.EDU (Richard J. Barbalace)
Thu Dec 16 13:24:40 1999

Message-Id: <199912161824.NAA11281@starbasezero.ne.mediaone.net>
To: chad brown <chad@akamai.com>
Cc: bug-sipb@MIT.EDU, sipb-office@MIT.EDU, cordelia@MIT.EDU, jik@MIT.EDU
In-Reply-To: Your message of Thu, 16 Dec 1999 16:24:12 +0000.
             <199912161624.QAA04345@egon.jyrc.org> 
Date: Thu, 16 Dec 1999 13:24:28 -0500
From: "Richard J. Barbalace" <rjbarbal@MIT.EDU>


> * We could remove the program from the sipb locker, and tell users to
>   use the web to find this information.  We could even hack together a
>   script or link or something to point them at a good place for
>   finding this information.

Wah.  As one of those users who actually uses sdate regularly, I'd
object.  I'd like to see it fixed, but as I'm leaving on Tuesday until
after New Year's, there's no way I'd've time to look at the code and
fix it myself by then.

One thing that is unclear from your mail:  Will sdate break after New
Year's when run with no arguments?  Or does it break only if a date
after 31 Dec 1999 is given as an option?  If only the latter, then
disabling the option (or giving a better error message) might be
adequate.  I didn't even know about the date option until you
mentioned it; how many other users are likely to be using that
regularly?

> * We could replace the packge with a totally different package.  I
>   just spent a short while looking and was a bit discouraged.

Adding another package might be worthwhile even if sdate is kept.

+ Richard

home help back first fref pref prev next nref lref last post