Pi is storing it's real-time data
as a combination of Values, as you see
here. These are individual Values for
this PI Tag called CDT158. And,
of course, each Value has a matching Timestamp.
So, Value, Timestamp;
Value, Timestamp. That's how we store the data.
Straightforward enough, right? Well, one of the things we do
is we want to make sure when we store that data, we store
it in a way that works no matter where you are
and no matter what type
of time zone configuration
you have got across your enterprise. So, if you are
spanning multiple time zones, and your servers
are in different time zones, and your clients are in different time zones,
well, how do you make something like that work? Well, thankfully,
this is not just our problem. This is a problem with the world
in general. There needs to be some kind of -- oh, let's call it
a Universal Coordinated Time, and, in fact,
that's what it's called. The, the UTC,
UTC by way, 'cause that's how the, it's written
in French, but the Universal Coordinated Time,
as we call it in English, is what we used to call
Greenwich Standard Time or Greenwich Mean Time, and
it's, it's basically the concept of storing these Values
as a single time zone,
this Universal Coordinated Time. Every time we
store a Value into the PI Server, that's how it's
stored -- as that Universal Coordinated Time.
So, any types of adjustments that need to be made
to that, such as if you are viewing it in
a different time zone, those are going to be made locally.
And, there's mechanisms to do that, as
long, so long as we have a common way we are
going to store this. So it does not matter what time
zone your computer's in, the PI Server's always going to store
this as this Universal Coordinated Time.
Now this does mean, for example,
when you have Daylight Saving Time in
your part of the world, if you do use that,
where, in which you have one
day of the year in which there's a 23-hour day, legally,
and another day in the year in which there's a 25-hour day,
legally, because you skip forward or backward in time.
Well, PI does not observe that
internally. Now, we do observe it from the point of view of the user.
But, internally, we do not. We store everything as
24-hour days. Now,
so, and the issue of time zone
is going to come up when it comes to reconverting data
to display at your local time. So, it, it's very
important when setting up these PI
Servers and setting up Interfaces, that on those
computers we set those computers up with the proper time
zone setting, and with the proper, well,
with the proper time, and, and whatever the rules
are for Daylight Saving Time in your part of the world. Now,
one other point I should make. Let me bring up a copy of ProcessBook
here. The, the Clients can be configured
such that they can,
they can display either the
Server Time or the Client Time. So, as
you can see, that's a choice that you can make on the client side
and that's, you know, that's one of the things that we do support
by, you know, by means of having
local conversions. We store everything the same way and then we
convert it locally. So that's an option and that's, you know, that's why
this gets complicated because you do have
servers and clients that span time zones. And, one more
point: Interfaces that are collecting data locally
are almost in all instances going to send that data
to the server using that Universal Coordinated
Time. They generally do that conversation locally and then send it
to the server with the timestamps already
converted. So, all of these,
these kind of changes that we see because of Daylight Savings
Time, all of these, you know, changes in time,
are handled properly when all of the computers in your system
observe the same rules. Now this is where we
bring into the conversation a file called
localhost.tz. This file
is located in your PI-dat Directory.
Here's an example of it right here.
This localhost.tz is what is used,
or what we use, for keeping track of when those
Daylight Saving Time changes occurred.
And you can inspect that localhost.tz
by using a Utility from, in the Command
Prompt within the PI-Admin Directory.
Now the Utility is called pidiag. It
does a lot of other things besides this, but
with the dash tz switch what we are doing
is were dump, dumping out the
Time Zone File, and I want to see a brief
presentation of this. What this is doing is showing me exactly,
you know, to the second, exactly when the
time changes, the Daylight Saving Time changes,
occurred on this particular computer, or
I should -- I should not say "occurred", but on
are observed on this computer. And
so, what do we mean by that? Well, as you can see here,
this is something that's stretching back all the way to the beginning of PI
time, which is 1970. It stretches all the way
into the future, 2037. That's
when we are going to have to switch to a different accounting method
for time -- us, us, and most of the rest of the world.
Anyway, those
dates that you see right there are the official dates
if, if the current
rules for Daylight Saving Time were in effect.
And, and you may notice if you are a fan
of history and DST, Daylight Saving Time,
this is a, this is interesting because it's
showing me the current US settings
which is to spring forward in March, and to fall backward
in November. It's showing
me, going backward in time, as thought those were the settings
while this server was running. In
fact, this is not the correct settings
if you are taking a look at what historically
happened in the US. In the US, we made a change in our
law back in 2007, where we pushed
everything forward. I think we pushed the,
the -- went into DST a month earlier, came out a month later.
So, traditionally, we'd gone in around April and came,
come out in October. Well, this
.tz file is showing us the algorithm as it
currently exists. Does this really make any
difference to an existing user? It actually does
because this Current Time Zone File, the way it's set up right now --
and this is a brand new install, remember --
this Time Zone File is going to set it up
so that if someone were to look at data from, say,
2005, they may actually see the wrong
timestamp because the -- you know, at that
time, according to our .tz
file here, we have, we were in DST, but, in fact,
we may not have been in DST at that point.
So, what we have done is, we have made
available to everybody for download
a series of DST Files,
these localhost.tz files,
that you can download, including one that's
going to be recognizing all
of the DST changes as they actually
occurred in, you know, the history of the US.
So, we, we have changed in 2007,
so we have got a .tz file that you can download
that would show you what this actually was, historically.
But, remember, if in your plant, you
use different times than what was used generally across
the US, and there's a large number of customers who have
done that. You know, they do not change over DST
at two in the morning because it's just too risky in a, in a
manufacturing environment. They prefer to wait the next day.
A lot, a lot of customers have
individual histories of their Daylight
Saving Time change, and if you would like
to create your own local host
.tz that will reflect those changes, in that
way, if anyone is looking back at historical
data, they are going to see the correct
time zones, or the correct, I should say, timestamps.
And I, I have heard the
complaint from some customers, hey, why cannot, you know, why cannot you just make this
automatic? Well, it's because of the fact that we have so
many customers who have customized their DST
behavior over the years, anything we would do
that would attempt to do this automatic, would probably hurt as
many customers as it would help. So, instead,
we have made a, a very robust,
very flexible, you know, very
powerful mechanism for doing
time zone and DST change
properly. Now, of course, whenever you hear the word "powerful" around
computers, that usually means it's very complex,
and there, there's no exception here. This is a fairly complex
issue. If you go into Knowledge Center,
within System Manger Resources, this is where you'd
find this Daylight Saving Time Section.
And, within here, what you will find is we make reference
to -- well, we make
reference to all the different issues surrounding
Daylight Saving Time, and we make reference to the
customized -- these .ts or
.tz files, the localhost.tz
files. If you want to actually get one of those customized
for your part of the world -- because we do have
custom local hosts for different regions in the
world -- just do a Search on
tech support for localhost.tz.
Just enter that as a Search term. What's you will see is
a list of the individual
local host files for different parts of the world.
This is where you would go if you wanted
to learn more about those customized localhost.tz's.
But, I am going to go in here, show
you this, this is a Knowledge Base Article. It's Knowledge Base Article
23410, or
23410SI8. This is where we go into detail
about that localhost.tz.
And then from here, you will find a link to where you can
download the one that,
it might be local for you. So, I am going to
go ahead and go to this Download Center here, and I am going to
download one that's going to be local for Central
Time in the US.
Yeah, see this lists, this lists
a lot of different things. It's under PI Server,
Extras, and what we are looking for is -- ... here
they are. Here are all the different ones for the different regions.
The one I want to look at here is this
localhost for USA and Canada, DST
2007. Now see, that recognizes the fact
that we put 2007 there 'cause that's when we
changed the law about how DST works. That's when
it was changed in the US and Canada. So,
and then you will see different ones for different
regions of the world as well. Now, I have already downloaded this.
This is a zip file, and I have already stored this
locally on my server,
right here. That's the file. Okay.
To put this in use what I need to do is, after I have
downloaded it, I need to just change it to localhost.tz.
Let's just look again, before and after.
When I have the original -- this is the original one that did not
reflect those changes in the law in
2007 -- this is showing me March and November
throughout the whole of history. But watch what happens
now when I rename this. I am just going to call this something
else. Let's call this localhostold,
and I will call this
localhost.tz. Now, after
you do that, you will have to stop and restart PI.
And now that I have renamed
that, I will go ahead and run the same Utility. I will just
press the Up arrow key, and
what you will see now is this localhost.tz
is informing the PI System
that the, you know, the Daylight Saving
Time change in 2006 was 29th of October,
but in 2007 it was 4th of November.
Now, again, you can create your own special one because
chances are you are not using 2 am as
that time change. Or you may or may not depending on
how, you know, you do things in your local enterprise.
So, if you have changed that so that you do this
at noon on the following day, then you can go in
and customize your own localhost.tz so
that when people are looking at the data historically, they will --
in PI -- they will see precisely the right
timestamps.