Re: Received mail timestamp is off by 7 hours

From: Anthony Atkielski (atkielski.anthony_at_wanadoo.fr)
Date: 02/27/05

  • Next message: Anthony Atkielski: "Re: Is Yahoo! moving from FreeBSD?"
    Date: Sun, 27 Feb 2005 10:36:35 +0100
    To: freebsd-questions@freebsd.org
    
    

    Pat Maddox writes:

    > I've included the headers of messages from both Gmail and Hotmail, to
    > show that it's not on Gmail's end. Also, here's the output from date:
    > %date
    > Sun Feb 27 02:42:21 CET 2005

    That can't be right. You sent your message in reply to a message I sent
    at 9:34 CET. The time on your local machine is incorrect by seven
    hours. It should be one hour ahead of UTC right now.

    > They should show up in my inbox as being received at 1:40am or so, but
    > they show up as 6:40pm instead.

    And 1:40 is exactly seven hours later than 18:40.

    The disparity is visible in the timestamps, too:

    >>From Gmail:
    >
    > Return-Path: <pergesu@gmail.com>
    > X-Original-To: pergesu@javaspot.net
    > Delivered-To: pergesu@javaspot.net
    > Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.198])
    > by cantona.dnswatchdog.com (Postfix) with ESMTP id 3161733C1B
    > for <pergesu@javaspot.net>; Sun, 27 Feb 2005 02:38:52 +0100 (CET)

    Notice that the timestamp on your local e-mail server corresponds to
    1:38:52 UTC, but the timestamp on Gmail's server ...

    > Received: by wproxy.gmail.com with SMTP id 67so1650347wri
    > for <pergesu@javaspot.net>; Sun, 27 Feb 2005 00:37:53 -0800 (PST)

    ... corresponds to 8:37:53 UTC, which is correct. The other timestamps
    for intermediate servers are also correct, but the timestamp generated
    by your machine on the original message is not ...

    > Date: Sun, 27 Feb 2005 01:37:53 -0700

    -0700 corresponds to MST (Mountain Standard Time in the U.S.), not CET
    (Central European Time).

    So the solution is to set the time and time _zone_ correctly on your
    machine. For a UNIX machine, the CMOS real-time clock should be set to
    UTC (what many people still call GMT), and then your time zone should be
    set to whatever is appropriate for your location (CET would correspond
    to most of Europe outside of the UK--here in France we are on CET).

    Are you by any chance running a dual-boot configuration? Windows
    expects the CMOS RTC to be set to local time. UNIX expects it to be set
    to UTC. If you are running only FreeBSD, you can just reset the CMOS to
    UTC and fix your time zone to match your location. If you are also
    running a boot of Windows or something like that, you'll have to leave
    the CMOS clock set to local time, and make appropriate adjustments.

    Unfortunately, I'm not sure which variables to change in FreeBSD, as
    I've always just set the time at installation time (when I'm asked if
    the local clock is UTC and what time zone I'm in).

    Maybe someone else can explain what needs to change in your FreeBSD
    configuration to set it to the correct time.

    In general, setting the time incorrectly on a local client machine in
    the SMTP protocol will produce seemingly random errors in the time on
    received messages, depending on the path they follow on their way to you
    (this is true even for messages you send to yourself). The local
    machine is almost always the one with the time set incorrectly
    (incorrect time on mail servers tends to be noticed by users very
    quickly, especially if more than one time zone is involved).

    -- 
    Anthony
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"
    

  • Next message: Anthony Atkielski: "Re: Is Yahoo! moving from FreeBSD?"

    Relevant Pages

    • Re: Preparing for daylight saving time changes in 2007
      ... What about any times that you are storing in your ... "TIMESTAMP WITH TIME ZONE is a variant ... and minutes) between local time and UTC ... TIMESTAMPWITH TIME ZONE ...
      (borland.public.delphi.non-technical)
    • Re: Java (new Date()).getTime() - java.util.Timestamp("select timestamp from dual").getTime() ??
      ... That's current time in session time zone. ... And to get it in UTC, ... SQL> select current_timestamp, systimestamp, ... Note that sys_extract_utcreturns TIMESTAMP, ...
      (comp.databases.oracle.misc)
    • Re: Question about ISO8601 vs. strftime()
      ... online references to ISO8601 just get it wrong? ... that link only shows the form with the UTC ... but not the offset as far as I can tell. ... assumed to be in some local time zone. ...
      (comp.programming)
    • Re: Time Zones as politics
      ... be in a different time zone from his arch-rival, ... we are not permitted to criticize him in any way because after ... UTC +5 AKA Eastern Standard Time. ... Soon upon the establishment of the Greenwhich Meridian as the time ...
      (alt.horology)
    • Re: SWbemDateTime to Win 2k Compatible
      ... UUU is number of minutes to subtract from current time to get UTC. ... The TimeWritten property is not an Integer8 value, ... ' Get current date/time less 2 hours. ... This assumes your time zone bias is -480 minutes. ...
      (microsoft.public.scripting.vbscript)