home *** CD-ROM | disk | FTP | other *** search
/ Source Code 1992 March / Source_Code_CD-ROM_Walnut_Creek_March_1992.iso / usenet / altsrcs / 1 / 1840 / README.getdate < prev   
Encoding:
Text File  |  1990-12-28  |  2.1 KB  |  38 lines
  1.  
  2. We've been using Steve Bellovin's getdate() routine in the Cronus project
  3. for over a year.  This past summer Jim Berets and I cleaned up all the
  4. timezones, cleaned up some int/long problems that others have found,
  5. reformatted the code and cleaned it up, and contacted Steve about what
  6. should else needs to be done with it.
  7.  
  8. Unfortunately, we didn't have the time to do anything much with Steve's
  9. comments, other then document them in the code, and here (thanks to Steve
  10. for letting me quote some email):
  11.     Two things need to be done.  First, the purpose of getdate should be
  12.     defined; many of its features were for a rather different purpose that
  13.     it's used for today.  Specifically, I was implementing 'at' before
  14.     there was such a thing, and I wanted the ability to specify relative
  15.     intervals.  Thus, getdate accepts things like 'two weeks'.  I don't
  16.     think that code is tremendously useful.  If it is, it could be
  17.     strengthened by writing a better grammar, i.e., ``two weeks after
  18.     monday'' -- currently, the word ``after'' isn't accept, and the
  19.     relationship between the day of the week and the interval is
  20.     peculiar.  And that in turn goes back to the central implementation
  21.     failure:  it is restricted to a simple 'int' stack, because that's all
  22.     that v6 yacc allowed.  There's also a lot of reliance on global
  23.     variables, for the same reason.  Using a union as the stack type, one
  24.     could store much better information, clean up the code, and make the
  25.     semantics much clearer.  (As a trivial change, I suspect that the
  26.     military time zones are wrong, as I took them from RFC822 (or maybe
  27.     even 733), and I've since learned that those are incorrect.  I'd drop
  28.     that entirely.) It might also be worth some effort to make the time
  29.     zone stuff more compatible with the 4.3tahoe and the SysVR3.2 stuff,
  30.     especially as regards the names of the zones.
  31.  
  32.     It was also intended to let utter novices set the date on a UNIX
  33.     machine after rebooting it and thus it accepted almost any rational
  34.     form.
  35.  
  36. Hope you find this useful.
  37.     /rich $alz
  38.