options on date

[David Collier]

OK, let me try that one more time

if you put -s "string" into busybox it interprets the string as if the -s
were not there, in other words as a default format string.
if you put -s "string" into big date, it accepts the string, but parses
it in a completely different way.

THEREFORE.

It does no-one any service for busybox to accept and ignore the -s
string.

If the command was intended only for busybox - it's meaningless

If the command has been ported across from big date, the string will not
be interpreted in a compatible manner, so appearing to accept it was
unhelpful.

Better to barf with a "'-s' not supported" message.

D

In article <AANLkTinLWDwhYOOwJaCjM0fAurmoWT+TuexLaQYF=Dm_ at mail.gmail.com>,
vda.linux at googlemail.com (Denys Vlasenko) wrote:

> *From:* Denys Vlasenko <vda.linux at googlemail.com>
> *To:* from_busybox_maillist at dexdyne.com
> *CC:* busybox at busybox.net
> *Date:* Mon, 17 Jan 2011 14:16:28 +0100
> 
> On Mon, Jan 17, 2011 at 12:29 PM, David Collier
> <from_busybox_maillist at dexdyne.com> wrote:
> > Just a thought...
> >
> > busybox seems to ignore the -s switch on date.
> 
> It doesn't ignore it: date -s DATETIME does set time.
> 
> > However - for the separately compiled "date" I looked at, -s 
> > switches the
> > date format over to something completely different.
> >
> > so
> >
> >  date -s "...."
> >
> >  would work under busybox, but give an error under Linux...
> 
> To paraphrase more clearly:
> 
> Bbox date treats
> date DATETIME
> and
> date -s DATETIME
> essentially the same (except for the MMDDhhmm[[CC]YY][.ss] case,
> which is supported only without -s).
> 
> Coreutils date supports both formats, but uses different syntaxes
> for DATETIME in them.
> 
> Why is this a problem?
> 
> > even when
> >
> >  date "same string"
> >
> >  would actually work fine under Linux
> >
> > Is there an argument for busybox rejecting the -s option as
> > "unimplemented" since we don't implement the data format it 
> > implies???
> 
> What data format does it imply?
> 
> And again, want to clarify: bbox date is more restrictive, and 
> possibly
> in some cases incompatible regarding DATETIME formats it accepts.
> I think the solution to that is to carefully extend the set of 
> accepted formats.
> 
> Tell me which format do you feel bbox date needs to be extended to 
> support?
> 
> -- 
> vda
>