Re: [foxboro] DST

Corey is correct. The problem is that we set time back and Mosaic doesn't like 
it.

In V8 of the I/A Series, we do not change the system time only the timezone. So 
the problem goes away (once we have Solaris on V8 anyway).


AJ

PS. Sprint is blacklisted and so I have to use another e-mail address. I know 
I'm going to regret putting this address on the list. Sigh...

----- Original Message -----
From: Corey R Clingo <clingoc@xxxxxxxxxxxxx>
Date: Tuesday, October 26, 2004 7:39 pm
Subject: Re: [foxboro] DST

> I think it is *I/A* version 8, not FV version 8, that will have 
> "time done 
> right".  It will utilize the Unix time zone facility properly 
> (it's, um, 
> about time...), so that the internal (GMT) system clock does not 
> change 
> when the time zone changes (only the translation to local time is 
> affected).  You won't have to set the clock forward or back.  It 
> is the 
> misuse of the Unix time facility in current I/A versions, which 
> inexplicably wasn't fixed during the transition from Venix to 
> Solaris, 
> that causes the current problems with DST changes.
> I also think it is Motif that does not update events, not X, as DM 
> and 
> other X apps do not seem to have difficulties when the clock is 
> set back. 
> Since I don't envision our getting I/A version 8.1 anytime real 
> soon, we 
> cooked up a script to set the time back, restart all the FVs, and 
> stop the 
> legacy historians for an hour to make this crap as painless as 
> possible.
> Corey Clingo
> BASF Corp.
> 
> 
> 
> 
> 
> 
> "Lowell, Tim:" <Tim.C.Lowell@xxxxxxxxxxxxxxxxxx>
> Sent by: foxboro-bounce@xxxxxxxxxxxxx
> 10/26/2004 10:51 AM
> Please respond to foxboro
> 
>              To:  foxboro 
>              cc: 
>         Subject:       Re: [foxboro] DST
> 
> 
> 
> 
> 
> 
> Oh, boy.  Have you opened up a can of worms, Sascha.
> 
> I love how they blame the X-server, and then say that FoxView v8 
> will =
> have "time done right".  Hmm, if it's the X-server's fault, and 
> FoxView =
> v8 runs on an X-server the same as FoxView 99.2.1, how could you =
> possibly fix it to make it "done right"?
> 
> Sorry, but I'm not exactly looking forward to coming in this 
> Sunday, so =
> cut me some slack.
> 
> Tim Lowell
> Control Systems Engineer
> ConocoPhillips Trainer Refinery
> (610) 364-8362
> tim.c.lowell@xxxxxxxxxxxxxxxxxx
> 
> 
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [foxboro-bounce@xxxxxxxxxxxxx] =
> On Behalf Of Sascha Wildner
> Sent: Tuesday, October 26, 2004 11:26 AM
> To: Foxboro DCS Mail List
> Subject: [foxboro] DST
> 
> Quoting from the Foxboro Customer Advisory:
> 
> -------- Original Message --------
> [...]
> After the clock is set back in time, all the screens using FoxView 
> will=20lock up and wait for the current date/time to catch up to 
> the latest=20
> time the FoxView display manager saw before updating any points or=20
> executing any operator commands. This Solaris FoxView issue is 
> related=20to the way that X-Window handles time stamps on event 
> messages. Each=20
> X-Window event is time stamped, and the X-Server makes sure that 
> events=20are not delivered before the "current" time. This is a 
> behavior of Motif =
> 
> applications such as FoxView and several Batch products that is 
> only=20found on the Solaris platforms.
> [...]
> ----------------------------------
> 
> I mean, is this really the X server's fault? Why does my own box 
> running =
> 
> under X not lock up for an hour upon DST changing? Isn't the time 
> you=20get when you type 'date' only a translation of the internal 
> time=20(seconds since Jan. 1, 1970) according to time zone rules?
> 
> I just want to understand this issue, any insight is appreciated.
> 
> Regards,
> 
> --=20
> Sascha Wildner
> erpicon Software Development GmbH
> Neusser Str. 724-726
> 50737 K=F6ln
> Germany
> 
> Phone: +49 221 9746069
> Fax:   +49 221 9746099
> eMail: swildner@xxxxxxxxxx
> 
> =20
> =20
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys 
> ProcessSystems (formerly The Foxboro Company). Use the info you 
> obtain here at
> your own risks. Read 
> http://www.thecassandraproject.org/disclaimer.html=20
> foxboro mailing list:             
> http://www.freelists.org/list/foxboroto subscribe:         =
> foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe:      =
> foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
> =20
> 
> 
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys 
> ProcessSystems (formerly The Foxboro Company). Use the info you 
> obtain here at
> your own risks. Read 
> http://www.thecassandraproject.org/disclaimer.html
> foxboro mailing list:             
> http://www.freelists.org/list/foxboroto subscribe:         foxboro-
> request@xxxxxxxxxxxxx?subject=jointo unsubscribe:      foxboro-
> request@xxxxxxxxxxxxx?subject=leave
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys 
> ProcessSystems (formerly The Foxboro Company). Use the info you 
> obtain here at
> your own risks. Read 
> http://www.thecassandraproject.org/disclaimer.html 
> foxboro mailing list:             
> http://www.freelists.org/list/foxboroto subscribe:         foxboro-
> request@xxxxxxxxxxxxx?subject=jointo unsubscribe:      foxboro-
> request@xxxxxxxxxxxxx?subject=leave 
> 

 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: