Date: Wed, 30 Jul 1997 14:03:20 +0930 (CST) From: grog@FreeBSD.ORG To: brian@awfulhak.org (Brian Somers) Cc: dk+@ua.net, brian@awfulhak.org, freebsd-hackers@FreeBSD.ORG Subject: Re: date(1) Message-ID: <199707300433.OAA00328@freebie.lemis.com> In-Reply-To: <199707291935.UAA20712@awfulhak.org> from Brian Somers at "Jul 29, 97 08:35:20 pm"
next in thread | previous in thread | raw e-mail | index | archive | help
Brian Somers writes: >> In article <199707290356.EAA22036@awfulhak.org> you wrote: >>>>> Yep. I think I'll fix the usage message too - shouldn't it be: >>>>> >>>>>> [yy[mm[dd[hh]]]]mm[.ss]] >> >> It should become >> >> [[[cc]yy[mm[dd[hh]]]]mm[.ss]] >> >> or we are screwed in 866 days from now. > > More like: > >>> cc[yy[mm[dd[hh]]]]]mm[.ss]] > > (you can't have the century without the year). Isn't that just what this syntax suggests? > I'll look into allowing this too. > > On that note, I'd expect a year of 00+n to mean 2000+n up to whatever > the maximum is. Any objections ? I'm still wondering whether this is the way to go. It seems that the number of permutations of individual options is just too much. I can't be bothered to check rigourously what potential there is for ambiguity, but consider: # date 2001 According to the above syntax, this means: Century 20, 1 minute I suspect that this isn't your intention, but I can't see how you can design a syntax which is unambiguous. Even if computers can understand it, people won't be able to. How about a more general parser which can understand dates written in a 'normal' manner. For example: 30 July 1997 14:2 July 30 1997 2:2 pm 30/7/97 14.2 14:2 97.7.30 Of course, deciding whether 4/3/97 means the 4th of March or the 3rd of April is something that will have to be determined in some other manner. Greg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199707300433.OAA00328>