Do you need to export data to other systems, where timestamping is done relative to the “real” UTC time, so that comparing data will fail?.This means that e-mail programs will have trouble to correctly timestamp mails sent in and out of your PCs. Are there other programs running on the IGSS machines that will be affected by this time zone change?For instance, if your PCs are on the Internet, they will be offset from the rest of the world.Except during the summer, of course, where the IGSS interfaces will offset the timestamp one hour to match the daylight saving time, but internally everything is still on normal time.īefore you make your choice, you should consider the following effects: In that case, the timestamps in the IGSS database will be equal to the timestamps shown to the user, both through the ODBC interface and other interfaces like reports, and data files will indeed be created and closed at the expected times according to their names. So, instead of setting the time zone to the actual physical time zone, consider setting it to GMT, Greenwich Mean Time, which equals the UTC time. However, when manually looking up data files covering a certain period, you must have this in mind. It may look odd, but it makes perfect sense, and it avoids the “missing hour” when entering daylight saving time and the “double hour” when daylight saving ends. During the daylight saving time period, the offset will be 2 hours. For instance, the IGSS log file “02120114.log” is containing data for the hour 14:00-15:00 on Decem– UTC time! so if you are located in the time zone GMT+1, like Denmark, it will contain data from the hour 15:00-16:00. This UTC strategy also means that data files designated to cover a certain period may not APPEAR to be created and closed at the correct time, even though they are. Furthermore, using the client-server version of the ODBC driver, it is not even guaranteed that the server and the client are located in the same time zone (though they probably are), so timezone calculations on the server may be misleading to the client. This is because ODBC is also used by IGSS itself, so it must follow the internal IGSS rules for timestamps, meaning it must show values in UTC. Inside IGSS, all timestamps are in UTC, but when data, like logged values and alarms, are made available to the user, the timestamps are recalculated in local time so that the user can understand and relate to them, without having to do manual time calculations.īut in the ODBC driver, for instance, the timestamps are NOT shown in local time, they are shown in UTC, exactly as they are stored inside the IGSS database. UTC is the best choice for timestamping, as Windows today offers functionality to make UTC available to programs together with local time which is actually calculated as an offset from UTC. UTC is the universal time, which is equal to Greenwich Mean Time, only it does not follow the changes in daylight saving time. Inside IGSS all timestamping is done using UTC. BUT before you choose, here are a few things to consider. What time and time zone do you choose to set on the PCs running IGSS ? Easy question – they should all be set to the same local time, of course, and the time zone should be set to whatever zone the PC’s are in.
0 Comments
Leave a Reply. |