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 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.
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
