Re: Time Puzzle (and DST update about the web link)

Karl,
On second observation, it looks like some of the times are reported in
UTC (or "GMT" time) and some are reported in CST. Your TZ variable
would be set to CST6CDT. The 6 is the number of hours that CST time is
offset from UTC time. This is why in one place it is reported at 21:32
and the other place it is reported as 15:32 CST. Try typing the
command:
TZ= date
Or
TZ=UTC date

BTW, many system log files are logged in UTC time. Also, watch out for
this when reading logs generated by syslog. Syslog does NOT convert the
time to a standard time zone such as UTC or the value of TZ in the
syslogd process, so client programs are free to report in whatever time
zone they desire. This is why syslog logs are in first-in-first-out
order, but the time stamps frequently switch between local time and UTC
time.

Sorry about my first answer, I should have read your question a little
more carefully.

Edward Davignon
Lead Analyst - Distributed Systems
Utility Shared Services - IT
Energy East Corporation


-----Original Message-----
From: IBM AIX Discussion List [mailto:aix-l@xxxxxxxxxxxxx] On Behalf Of
Karl
Sent: Sunday, February 04, 2007 12:21 AM
To: aix-l@xxxxxxxxxxxxx
Subject: Re: Time Puzzle (and DST update about the web link)

No we do not use NTP. Just to stress, I am not concerned
about the time being off on our system. It seems accurate
to me. Further, we have made no significant changes to
our system in months.

What is puzzling to me is how I can have a record of
myself signing in from a machine whose time I am also
confident of and have a time discrepancy of multiple hours
when both are in the same time zone and set as such.

==============================================

Karl,
Are you running Network Time Protocol (NTP)? Did you have
a
misconfigured NTP server in your NTP configuration?

Without Network Time Protocol (or another clock discipline
method), most
clocks will use the AC cycle (60 HZ in the USA) as their
reference
frequency and will drift wildly depending on the quality
of the power.
Power conditioning will help, but NTP should keep the
clocks in sync
with each other. There are NTP hardware devices
(appliances) that
receive radio signals that are broadcast by governments
that keep your
clocks in sync with a national standard clock.

Also, if you lose power and switch to a local generator,
the quality of
the power from a local generator tends to vary frequency
by the load of
the generator, this will drive the clocks crazy too. I
found this out
when I ran my alarm clock off a generator that was running
at 62 HZ. By
morning, my alarm clock was significantly ahead of my
battery-powered
clocks!


Edward Davignon
Lead Analyst - Distributed Systems
Utility Shared Services - IT
Energy East Corporation

-----Original Message-----
From: IBM AIX Discussion List [mailto:aix-l@xxxxxxxxxxxxx]
On Behalf Of
Karl Jones
Sent: Friday, February 02, 2007 10:03 AM
To: aix-l@xxxxxxxxxxxxx
Subject: Re: Time Puzzle (and DST update about the web
link)

I have not been experimenting with TZ. Further, in one
instance, the
user is me from a machine which I know is set for the same
time zone.
Nevertheless it is the only lead I have so far so I will
look into it.

Andrew.Townsend@xxxxxxxxx wrote:
Let me guess, you're experimenting with the TZ ?

I am testing the chtz command and I have seen that same thing as
well.

By the way, if you are looking at this website that shows you how to
change
the timzone information to reflect the upcoming changes in Daylight
Savings
Time (only for those of use that aren't at the supported level):

http://www-1.ibm.com/support/docview.wss?rs=0&uid=isg3T1000252

The command on the website shows this command (For EST):

chtz TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

The command should be:

chtz EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

I called IBM and told them so hopefully it will be changed on the
website
soon.

Once the command is run, check the /etc/environment and look at the
TZ=
line. If you use the command shown on the website you will see:

TZ=TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

what you want to see is:

TZ=EST5EDT,M3.2.0/2:00:00,M11.1.0/2:00:00

Drew





Karl Jones

<kjones@stpaullin

ocpt.com>
To
Sent by: IBM AIX aix-l@xxxxxxxxxxxxx

Discussion List
cc
<aix-l@Princeton.

EDU>
Subject
Time Puzzle



02/01/2007 04:47

PM





Please respond to

kjones@stpaullino

cpt.com









I am puzzled by the date stamps here. How is this possible?

Last unsuccessful login: Thu Feb 1 20:58:34 2007 on ssh from
221.208.160.11
Last login: Thu Feb 1 21:32:06 2007 on ssh from karl-jones
[snip]
F50:/ # date
Thu Feb 1 15:32:40 CST 2007



Relevant Pages

  • Re: Success! FC6 and AMD64 problems
    ... mention other groups where GMT is not exactly the same as UTC. ... I always figured the change in NTP and friends was meant to underscore ... an average of a dozen or so of the worlds most accurate clocks.) ...
    (Fedora)
  • Re: Time Zones (Was: IBMLink is UP - just kidding)
    ... global conferencing has a half dozen clocks on the wall, ... Of course, once you get into UTC, analog clocks don't work so ...
    (bit.listserv.ibm-main)
  • Re: definition of simultaneity and on the relativity of lenghts and times by a. einstein
    ... >> at places remote from the watch. ... traversing space as a modulated EM wave, the report must be dilated ... identical time readings, reported by universally synchronized clocks, ... accelerated to new coordinates within the observable universe, ...
    (sci.physics.relativity)
  • Re: The Spin Proviso to Relativity
    ... >> However, if the two clocks were showing UTC, they would NOT ... >> in the Earth fixed frame. ... His clocks belong to a frame that IS rotating. ...
    (sci.physics.relativity)
  • Re: The Spin Proviso to Relativity
    ... and I say that this IS how we synchronize clocks on the Earth. ... >> these UTC clocks, you will find that it is different from the time ... >> that it will use the same time in both directions. ... > It must get messy if you try to concoct an inertial frame to ...
    (sci.physics.relativity)