"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
| Hello there,
|
| I would like to report a bug in the "date" command. The -R (--rfc-822)
| option is specified in order to make "date" output an RFC-822 date
| string. Unfortunately, it is broken in any non-English locale:
|
| : korell 38 ; echo $LANG
| sv_SE
| : korell 39 ; date -R
| tis, 25 jan 2000 07:25:59 -0800
|
| ... which is definitely not an RFC-822 compliant date string. RFC-822
| dates contain specific strings for weeksdays and months which happen to
| be abbreviated English words. However, that aspect is incidental to it
| being a specific code string specified in RFC-822, and which is
| parseable by every mailer on the planet.
|
| Based on the definition of -R (--rfc-822) which, incidentally, I was
| part of adding to sh-utils, it is obvious this is not the intended
| behaviour. I have reported this bug before, and was unfortunately told
| in quite rude language to "use the C locale if you want portable
| behaviour", effectively claiming that the locale system is wasted on a
| program as common as a mailer! This is obviously beyond ridiculous.
I presume you didn't report it to this list (or maybe I missed it
somehow?) since this doesn't ring a bell with me.
| I would therefore suggest one of these two solutions; either of which
| I'd be happy to implement if requested:
|
| 1. Either force the locale to "C" if the -R option is specified around
| the call to gnu_strftime(). However, error messages should still be
| given in the local language, if applicable. This would mean specifying
| -R and a "+" format would mean the "+" format would be rendered in the C
| locale.
#1 is the way to go.
| 2. Or don't use gnu_strftime() at all if the -R option is specified;
| rather, use an ad hoc time-formatting routine. This would mean
| specifying -R and a "+" format would mean the "+" format would be
| ignored.
|
| Please let me know your preference.
|
| -hpa
