On 06-Mar-2001 Rod... Whitworth wrote:
> On Tue, 06 Mar 2001 11:40:29 +0100 (MET), Stefaan A Eeckels wrote:
>
> On 04-Mar-2001 Rod... Whitworth wrote:
> > Does this have any bearing on his problem? I don't know as I have not
> > been following it in detail. The -0000 just hit my eye.
>
> The -0000 is in the MTA generated Received: lines. AFAIK, it's
> the standard way to indicate "no offset from UTC".
>
>
> What standard are you quoting?
> RFC822 says that UT representation is +0000
> RFC1123 point out that 822 gets MIL tz codes bass-ackwards so -0000
> should be used as defined in 822 as operational difficulty or invalid
> tz code.
According to D J Bernstein (from http://cr.yp.to/immhf/date.html#timestamp ):
: The time shown is the creator's local time. The time shown, minus the zone shown, is
: the actual time in UTC.
:
: Exception: a zone of -0000 indicates that the local time is unavailable or
:meaningless,
: and that the time shown is the actual time in UTC.
: (In contrast, a zone of +0000 indicates that the times hown is both local time and
: actual time in UTC.) This special meaning of -0000 was not specified in 822, but it
:is being
: widely used and is mentioned in 822bis.
:
: Note that, in a few areas of the world, the difference between local time and UTC is
: almost never an exact multiple of 1 minute.
: Implementors can still use -0000 safely in this case.
Stefaan
--
How's it supposed to get the respect of management if you've got just
one guy working on the project? It's much more impressive to have a
battery of programmers slaving away. -- Jeffrey Hobbs (comp.lang.tcl)
