Re: Received mail timestamp is off by 7 hours

From: Pat Maddox (pergesu_at_gmail.com)
Date: 02/27/05

  • Next message: Anthony Atkielski: "Re: Received mail timestamp is off by 7 hours" 
    Date: Sun, 27 Feb 2005 03:10:12 -0700
To: freebsd-questions@freebsd.org

    Alright, I got it all working now. Not sure how to change the time
    zone with config files, so I just used sysinstall to change it to MST
    (time zone is arbitrary, but since this is the zone I live in, it's
    convenient for me). Then I used ntpdate to sync it, and it's working
    well now.

    Thanks for pointing that out to me. I just thought that CET was central time :)

    On Sun, 27 Feb 2005 10:36:35 +0100, Anthony Atkielski
    <atkielski.anthony@wanadoo.fr> wrote:
    > 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"
    >
    _______________________________________________
    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: Received mail timestamp is off by 7 hours"

    Relevant Pages

    • Re: [git pull] x86/hrtimer/acpi fixes
      ... Movable zone start PFN for each node ... Using ACPI for SMP configuration information ... CPU: Physical Processor ID: 0 ... # Firmware Drivers ...
      (Linux-Kernel)
    • Re: Avoiding domain mismatch (TCPIP Services)
      ... up my TCPIP$BIND.CONF file and zone files, ... $ TCPIP SHOW ROUTE/PERMANENT ... Communication Configuration ... TTL set ...
      (comp.os.vms)
    • Re: /etc/resolv.conf changes
      ... DNS records files, the configuration is caching nameserver; ... {#Settings for the ROOT ZONE ... type master; #Specifies this as a MASTER ZONE ...
      (Fedora)
    • Re: First time config - room for improvement?
      ... sample as I said) is also setup to assume that $CHROOT/var/named/data is ... Well putting a zone file through named-checkconf will produce ... I get the $TTL warning in the original config under BIND 9.5.0 (as I ... The sample configuration covers SELinux, which is why it is writing ...
      (comp.protocols.dns.bind)
    • Re: missing information from forestdnszones / domaindnszones
      ... DNS is not installed on all DC's. ... If the zone was AD integrated, it acts as a primary zone on any DC ... on to their respective Site DCs (and the app partitions don't have anything ... SRV records to reflect the new configuration, ...
      (microsoft.public.windows.server.dns)