On Mon, 20 Aug 2001, Alan Shutko wrote:
> "C. Scott Ananian" <cananian@lesser-magoo.lcs.mit.edu> writes:
>
> > You're not paying attention. =) The locale information is used for both
> > input and output (see 'man strptime' for example).
>
> strptime is extremely limited, since it only handles whatever it's
> been told to. It assumes a "one format for input, one format for
> output" mode. As a user, you may want to use "yesterday",
> "2000-12-32", 12-June-2001, and other things in the same command
> line.
AAAARRRGGGGHHH! I WASN'T SUGGESTING USING STRPTIME!
I was just mentioning that there are POSIX functions (actually, I guess
XOPEN standard in this case) which use *locale* to determine *input*
format and so that idea that locale was output-only was misguided.
> The problem with using LC_TIME is that you may want the system to
> interpret [0-9][0-9][/-][0-9][0-9][/-][0-9][0-9][0-9][0-9] on entry as
> MM/DD/YYYY, but see YYYY-MM-DD in output. How do you specify that
> with LC_TIME? Furthermore, how do you specify the formatting at all
> with LC_TIME, other than finding a locale that happens to do what you
> want?
OK, so *now* I'll suggest using strptime.
strptime throws an error if the input does not exactly match what it is
expecting. one possible way of handling the parsing task is to have a
chain of "hypothesis" parses: try parsing as ISO-standard date/time, try
parsing as "yesterday" words, and then (finally) try parsing as a few
varieties of the locale-specific format. The *can* be done with LC_TIME.
Of course, if you specify LC_TIME as ISO-format, then you give up one of
your possible input formats, but That's Okay.
I agree with some of the other posters that ISO-formats should certainly
be recommended (especially in scripts!). But I think that locale-specific
shortcuts (read, "specifying the date the way the user is used to" should
not be discarded.
Another place this comes up is time-zones, of course. CVS (and GNU
getdate, I believe) defaulted to GMT for all times. The intuitively
correct thing is to use the user's local time zone for all specifications
without an explicit time zone, of course. This means that scripts may,
indeed, "behave differently" for different users if incomplete time
specifications are used. I don't see that as a problem.
--s
Indonesia quiche non-violent protest Leitrim pending Kojarena assassination
Castro global action network SSBN 731 Mk 48 blowfish Kennedy RUCKUS
( http://lesser-magoo.lcs.mit.edu/~cananian )
--
"These students are going to have to find out what law and order is
all about." -- Brig. General Robert Canterbury, Noon, May 4, 1970,
minutes before his troops shot 13 unarmed Kent State students, killing 4.
--
[http://www.cs.cmu.edu/~dst/DeCSS/Gallery/]
#!/usr/bin/perl -w
# 526-byte qrpff, Keith Winstein and Marc Horowitz <sipb-iap-dvd@mit.edu>
# MPEG 2 PS VOB file on stdin -> descrambled output on stdout
# arguments: title key bytes in least to most-significant order
$_='while(read+STDIN,$_,2048){$a=29;$c=142;if((@a=unx"C*",$_)[20]&48){$h=5;
$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$b=73;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=($t=255)&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*8^$q<<6))<<9
,$_=(map{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;$t
^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271))
[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}print+x"C*",@a}';s/x/pack+/g;eval
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:36 2006