Re: [foxboro] How to keep accurate time

  • From: "Brown, Stanley" <stan.brown@xxxxxxxxxxxxxxxxx>
  • To: "foxboro@xxxxxxxxxxxxx" <foxboro@xxxxxxxxxxxxx>
  • Date: Tue, 26 Feb 2013 12:48:49 +0000

Actually I think the correct way to do this is a lot like *NIX deals with this 
from the user interface point of view. The system clock is set to UTC. When I 
log on, I set (automatically) an environment variable that tells the system 
what time zone I am in, and it presents the data in a format corrected for my 
view of the world. Thus if I am logged onto a computer physically located on 
the West coast of the US, and I am physically on the East coast, I see the time 
as the format I expect (locally).

The only issue with this has to do with historical data, and the continuing 
meddling with DST start/end dates by the politicians. The system does have a 
file /etc/tztab that tells it what the current value of these change dates is, 
but (currently) the format of that file does not allow for a start and end date 
of the effective time of the start end dates of the DST change. Guess we will 
have to enhance the software to compensate for the politicians :-)


> -----Original Message-----
> From: Stan Brown [mailto:stanb@xxxxxxxxx] On Behalf Of Ken Heywood
> Sent: Tuesday, February 26, 2013 7:37 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] How to keep accurate time
>
> This is just an observation for what it's worth:
>  <rant>
> For 50 some years the process industry has used computers to
> control/gather process data. In that 50 years, nobody has figured out
> that you just don't grab just the time/date to index a piece of data
> for archiving. You also need to record the time zone. The issue has
> always been how to store the process value for 2am EST or EDT around
> the time change. The answer has always been you can't. Each time slot
> is unique in that time change interval. If you record only time/date,
> the computer (and human) gets confused. Sure, your historian must store
> an extra byte for each value to account for 2 hours of data slots each
> year. But the logic will work every time instead of crashing the
> software once or twice a year in the wee hours. And you'll have a side-
> effect, because you store TZ, you'd be able to synchronize events
> worldwide across databases.
> </rant>
>
>
> Thank You,
> Ken Heywood
> Calibration Laboratory Manager
>
> PROCESS CONTROL SERVICES, INC.
> Established in 1983
>
> http://www.processcontrolservices.com
>
> mailto:KHeywood@xxxxxxxxxxxxxxxxxxxxxxxxxx
> Telephone: 734-453-0620
> Wireless: 508-241-2040
>
> ===============================================
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-
> bounce@xxxxxxxxxxxxx] On Behalf Of Dirk Pauwels
> Sent: Tuesday, February 26, 2013 3:28 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] How to keep accurate time
>
> Philip,
>
> We've had this kind of problems also on 6.3, 8.4 etc....
> When the clock is turned back an hour, PI lists stop collecting data.
> Strange thing is that the PI server is time synched by NTP because it's
> an ADMIN server, not a DCS server. It hasn't got a problem with it
> being at 7pm and the DCS timekeeper being at 8pm, |(errors but no
> crash), but as soon as the master timekeeper DCS is changed to 7pm, PI
> crashes. I usually stop PI and INbatch to change the time manually if
> we have to turn the clock back. Forward is no problem, this can be done
> online.
> We had the same problem with our former I/Abatch, (replaced by InBatch
> ),  it needed to be stopped when we wanted to turn the clock back 1
> hour. We had plenty of problems when DST on the DCS timekeeper was in
> AUTO. (the way this setting is presented in the system manager is very
> confusing). Batches blocked, PI crashed etc....
>
>
> Rgds,
>
> Dirk
>
>
>
>
> _______________________________________________________________________
> 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:             //www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>


________________________________

The information contained in this message and any attached files may be 
privileged and/or confidential and protected from disclosure. If you are not 
the intended recipient, any disclosure, copying, distribution or use of any of 
the information contained in or attached to this transmission is strictly 
prohibited. If you have received this transmission in error, please so notify 
the sender immediately without reading it. Also, please promptly destroy the 
original transmission and its attachments. Any views or opinions presented in 
this message or attachments are those of the author and do not necessarily 
represent those of KapStone Paper and Packaging Corporation or its subsidiaries.
 
 
_______________________________________________________________________
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:             //www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts:

  1. Home
  2. foxboro
  3. Archive
  4. 02-2013