D3 Release Version 7.4.2.LINUX
Installed tzdata file for the DST time change out here in California.
It appeared to me that DST worked just fine on the Linux box. I
happened to be up at 1:59am and I watched the time change from 1:59:59
to 3:00:00. I thought GREAT...no problem.

Console and telnet sessions are an hour behing the green screens.

Here is what a telnet session shows when at TCL in D3:

:08:40:18 12 Mar 2007
:time
08:40:20 12 Mar 2007 Monday
:!date
Mon Mar 12 08:40:49 PDT 2007
:time
08:40:25 12 Mar 2007 Monday
:

Here is what is shown on a green screen terminal over a serial
connection:

:time
07:41:28 12 Mar 2007 Monday
:!date
Mon Mar 12 08:41:57 PDT 2007
:time
07:41:32 12 Mar 2007 Monday


Any ideas? Why would TCL report the current system time differently
via telnet from a serial connection?

On Mar 13, 3:45 pm, "num7" <arothlisber... (AT) gmail (DOT) com> wrote:
My understanding is the D3 keeps its own time. Therefore you must
also change the time in the D3 environment.

For the time change to DST I had a background job fire up change the
time, and update the start times for several background jobs.

It worked great for me.

ymmv

Dale

On Mar 13, 4:09 pm, "Dale" <dale_bened... (AT) flightcraft (DOT) ca> wrote:
Thanks...but now even when changing the time, the telnet sessions
and all serial terminals are still off by an hour from each other.

D3 may have its own time but it displays as two different times now.

My bet is that the telnet D3 session is started on demand, whereas the
serial sessions were started a long time ago (at boot?). Try re-
starting the D3 serial sessions and see if solves your problem.

/Scott Ballinger
Pareto Corporation
Edmonds WA USA
206 713 6006

I played around with it for awhile on my D3/Linux 7.4.2 server as well. I
got unpredictable results unless I reset the time in Linux and D3 in order.
This is what I did:

from tcl:
!date --set=08:00:00 (sets the time in Linux)
set-time 08:00 (sets the time in D3)


"num7" <arothlisberger (AT) gmail (DOT) com> wrote

Here's what I run on a nightly basis to keep my D3 time and date synced to
Linux

EXECUTE '!date' CAPTURING OUTPUT RETURNING OUTPUT2
OUTPUT = OUTPUT[12,99]
CONVERT CHAR(32) TO CHAR(254) IN OUTPUT
TME= OUTPUT<1>
CRT "TIME SYNC'D TO ":TME
EXECUTE 'SET-TIME ':TME
!
!
EXECUTE '!date' CAPTURING OUTPUT RETURNING OUTPUT2
DAY = TRIM(OUTPUT[1,4])
MONTH = TRIM(OUTPUT[5,4])
DNUM = TRIM(OUTPUT[9,3])
YEAR = TRIM(OUTPUT[25,4])
BEGIN CASE
CASE MONTH = "Jan"; MONTH = "01"
CASE MONTH = "Feb"; MONTH = "02"
CASE MONTH = "Mar"; MONTH = "03"
CASE MONTH = "Apr"; MONTH = "04"
CASE MONTH = "May"; MONTH = "05"
CASE MONTH = "Jun"; MONTH = "06"
CASE MONTH = "Jul"; MONTH = "07"
CASE MONTH = "Aug"; MONTH = "08"
CASE MONTH = "Sep"; MONTH = "09"
CASE MONTH = "Oct"; MONTH = "10"
CASE MONTH = "Nov"; MONTH = "11"
CASE MONTH = "Dec"; MONTH = "12"
END CASE
DTE = MONTH:'/'NUM"R%2":'/':YEAR
CRT "DATE SYNC'D TO "TE
EXECUTE 'SET-DATE 'TE

Glen

"num7" <arothlisberger (AT) gmail (DOT) com> wrote

"num7" wrote:

I'd guess the problem is related to when D3 gets the time from the
host OS. I can't explain it with any specific knowledge but it looks
like D3 got the time for serial ports when D3 was started, because
that's when those ports are initialized. But telnet sessions are
separate processes initialized on connection (I think) so D3 has to
get the time from the environment on each connection. Looks like a
bug. Rebooting D3 should fix it but you should advise RD to look into
this since you will probably have the same problem this fall. For
what it's worth, it looks like the same issue might be in jBASE.

Other hangovers from the change to DST:

Issues with cell phones, Outlook Appointments, and my own blog running
over RHEL. Duh.

Issues were reported with the Sun/Java tzupdater.

With no patches from Oracle (to my knowledge), 9i and 10g clients had
some issues.

Some Cisco phone systems weren't entirely prepared.

Some VOIP phones were affected.

Some BlackBerry users were affected: DST updates were made available
in BlackBerry Enterprise Server version 4.0 Service Pack 6 or version
4.1.

Many Fax machines need manual changes, and (who'da thunk it?) some
high-end printers from Xerox, HP, and Minolta.

Some GPS devices didn't change.

Other devices like personal clocks that include or use atomic clocks
were also affected.

Some routers didn't change.


Overall the whole thing went well.

T

Don't forget solar calculators by SunWeld, you need to reboot 'em, Viking
6-burner ranges (2001-2002 only,) and anything built by GM.

Chandru

"Tony Gravagno" <address.is.in.posts (AT) removethis (DOT) com.invalid> wrote in
message news:a8bev21kglntejlu5u8sjn823985mdvhnq (AT) 4ax (DOT) com...

Something I just noticed on 7.4.2 Linux is that background processes
don't notice the change in time. I have a few process that sleep, do
their thing and then sleep again, and they were waking up an hour late
until I ended them and restarted them.

I had the same thing happen. I checked the console time Sunday
morning - It had updated just fine. Late Sunday evening I happened to
check the timeclocks running off a serial port - they were an hour
off! I just disconnected (Turnkey) each of the serial ports and when
they restarted the time was correct.

Dave G

On Mar 13, 6:45 pm, "num7" <arothlisber... (AT) gmail (DOT) com> wrote: