Leviton A8812, Инструкция по установке и эксплуатации

Страница: 33 / 48

33
11 SYSTEM OPTIONS
If you store data in local time, you will have the following issues.
1.
Local time is relative. Is Local the time where the DAS exists, or local to where the data is stored? If
local to the DAS , you must shift each DAS data set depending on its location.
2.
There are about 11 time zones in the US. Some observe DST, others do not. These include Alaska, the
Aleutians, Arizona, Central, Eastern, Hawaii, Indiana, Michigan, Mountain, Pacific, and Samoa.
3.
When converting to local time, there will be one hour of overlapping data in the fall when the time is
adjusted for Daylight Savings time, ie, log entries run 12:45, 1:00, 1:15, 1:30, 1:45, 1:00, 1:15, 1:30,
1:45, 2:00am. This will prevent you from sorting your data by time in your database.
4.
In the spring, you will have a gap in the data from 1:59 to 3:00am. This can cause problems if you are
calculating demand values based on consumption.
5.
Converting local time to any other timezone usually involves converting it to UTC first.
Using UTC time solves these problems elegantly. The best practice is to store data in the database in UTC
format and then convert the information when generating a report for the user. For example, if you wish to
draw a graph of KW over Time, prompt the user for a date range, i.e., Jan 1 midnight to Jan 2 midnight.
Take the user specified end points and convert these times from local time to UTC. Next, create an SQL
query using the new UTC formatted data as your select statement. i.e:
SELECT * from TABLE where time > ‘2003-01-01 08:00:00’ and time < ‘2003-01-02 08:00:00’
Note the time is 8 hours ahead of local time. This example is for Pacific which is 8 hours off from UTC.
This will return a list of data points between the two specified time ranges. Next, plot the data on a graph,
using the UTC times for start and end points. Finally, when drawing the ‘time’ legend on the graph, convert
the values back to Local time before displaying. i.e., 2003-01-01 00:00:00 to 2003-01-02 00:00:00. Any
division lines on the time axis can be handled the same way. The advantage of using this technique is that
it will properly draw a graph across DST change boundaries. The graph axis is based on UTC time with no
DST, and will not show a gap or overlap a the time of the change. The axis labeling will be correct as well,
matching the UTC times precisely.
Another way to handle the conversion is to query and convert all the returned timestamps to local time
before drawing the graph. This is useful if you do not have detailed control over the graph legend drawing
process. This technique will not properly graph across DST changes as the graph is based on local time
including DST changes.
11.5 System logs
The DAS can keep several log files that report the general operation of the system, not related to the
normal data logs. These include the following:
Debug Messages: The DAS can run a “syslog” process to record more detailed information about its
operations, however this log consumes vast quantities of memory quickly, and is disabled by default. Click
the “start log” button to enable the feature. Click the “end log” button to disable. Note: when the DAS is
rebooted, the debug log will be disabled on startup.
Kernel Boot log: Startup messages about the Linux operating system startup. This log shows what
hardware items were detected and initialized.
WEB
VERSION