Following today's teleconference, I've been looking into the role of
LC_TIME in *sending* messages. We all agreed on *reading* messages that
LC_TIME should have no effect on the content of the message, though it
might effect the summary lines provided by the "Display Header Summary"
command. However, the standard currently does not address the format of
these lines.
In at least the Linux case, mailx does *not* add a Date: header, but
leaves this to the "sendmail" program (from the sendmail variable, which
is not in the standard). Since this is not a standard variable, and
RFC-822 requires a Date: header line, it is perfectly possible that some
mailx implementations *might* add their own Date: line, but the format
of this line is dictated by RFC-822, and does not support localization.
Therefore LC_TIME should not affect this.
There is also a "From " pre-header line, which includes a date, that
comes from the ctime() function (i.e. is not locale aware). This line is
not addressed by the standard.
Interestingly, the rationale (p 607, lines 23506-23511) states:
The description of LC_TIME uses "may affect" because many historical
implementations do not or cannot manipulate the date and time strings in
the incoming mail headers. Some headers found in incoming mail do not
have enough information to determine the timezone in which the mail
originated, and, therefore, mailx cannot convert the date and time
strings into the internal form that then is parsed by routines like
strftime( ) that can take LC_TIME settings into account.
Changing all these times to a user-specified format is allowed, but not
required.
However, this rationale is no longer in line with the normative text ...
the original 1992 wording was:
LC_TIME This variable may determine the format and contents of the date
and time strings written by mailx. This part of ISO/IEC 9945 specifies
the effects of this variable only for systems supporting the User
Portability Utilities Option.
I would propose that we return to this wording, or at least the first
sentence of it.
--
Nick
On Fri, 2004-03-19 at 06:54, yyyyyyyyyyyyy@xxxxxxxxxxxxxxxxxxxxx wrote:
> Defect report from : Gunnar Ritter , n/a
>
> (Please direct followup comments direct to yyyyyyyyyyyyyy@xxxxxxxxxxxxx)
>
> @ page 0 line 0 section mailx comment {n/a}
>
> Problem:
>
> Edition of Specification (Year): 2003
>
> Defect code : 3. Clarification required
>
> The following text in utilities/mailx.html,
>
> # LC_TIME
> # Determine the format and contents of the date and time strings written
>by mailx.
>
> seems to imply that all date and time strings written by mailx should be
>affected by the current locale. However, this may not affect date and time
>strings in Internet email and following the Unix 'From_' lines, because it
>would otherwise violate RFC 2822 or confuse implementations, respectively.
>Existing implementations seem to follow this rule in general.
>
> Moreover, existing implementations generally seem to simply copy the date and
>time string following the 'From_' line of messages to the output when
>displaying header summaries. In effect, date and time strings are thus always
>shown as in the POSIX locale.
>
> In IEEE Std 1003.2-1992, the text for LC_TIME was 'this variable may
>determine . . .'. This is still mentioned in the current rationale, but not in
>the standards text.
>
> Action:
>
> In any case, it should be made clear that LC_TIME does not apply to any parts
>of message formats, even if these formats are outside the scope of POSIX
>anyway.
>
> LC_TIME should be made optional for mailx again.
|