"Rubin, Gary" <[EMAIL PROTECTED]> wrote: >I am also interested in this issue... Do you mind sharing some of the >feedback you got? I didn't see any responses in my Info_Labview daily digest.
I didn't answer this one but principally it is so that the LabVIEW timestamp is really in seconds since 0:00 UTC, Jan 1, 1904. This means the timestamp is always considered to be in UTC = GMT. However any and all LabVIEW functions which do display absolute time, do convert this time to the actual local time before displaying it. This is mostly right in a desktop centric environment where users are used to have local times with automatic daylight saving time switching and such, but for certain applications such as data logging it can be disturbing if the time you see on the x axis suddenly seems to jump for 1 hour because of this automatic time switching. Also data acquired in Australia will be maybe acquired at 12pm but the internal timestamp is something like 12am and when you display that data with the timestamp in central US it will seem it was acquired at 7 am the following day. The problem is that this is all right in terms of absolute universal time because at the time the data was taken it was really 7am the next day in the US. More problems are added because of daylight saving time and the fact that there is no algorithm which can possibly predict if a certain timestamp was daylight saving or not, because for that you also need to know the actual geographic location and a huge database of dates when and how much the daylight saving time changed for that particular place. Not all places in the world use daylight saving time, some have changed that multiple times in the last century, some switch or have switched on other dates, and some do not use an offset of 1 hour for that purpose. There are a few solutions. The first and most simple one is to not use local time. Standardize on UTC for at least those machines you need to log the data and also display them later on. Times will seem strange in the beginning but all the time zone offsets are gone and 12am is 12am for anyone involved as long as he is told that this all is in UTC. Another one is to determine the offset of your local time zone. There are VIs on Developer Exchange originally developed by Stepan Riha from National Instruments which do just that with standard LabVIEW built in functions. Store this offset together with the timestamps (you won't need more than one offset per day) and when reading the data back you have to decide if you want the data to be presented in the original local time, in UTC or in your current local time. Depending on that decision you adjust each timestamp with the original offset and/or the current offset and display it. As time is a complicated issue, there is little LabVIEW for itself could do to make it in a way which would please everybody. The only suggestion I would have for LabVIEW is to add an additional formatting specifier which tells LabVIEW to not adjust for the local time zone offset when displaying a timestamp but instead display as UTC directly. "George Gatling (Contractor)" <[EMAIL PROTECTED]> wrote: >However, this is IMHO still a workaround (one I intend on using though)... >the time stamp control is defined as UTC, so when I poke around with it to >get the format function to work the way I want I am in effect going against >the definition of the time stamp control. If I started passing this >modified time stamp around, things could get *quite* confusing. So to the >fellows at NI... isn't it about time we got a little more control over the >format date/time into string function? Just adding two inputs, one for >whether to use daylight savings and another for which time zone to use would >probably cover most needs... and if unwired, there terminals could default >to the system settings. That way the new features would not have to break >existing code. Just a thought. As pointed out above, the UTC format specifier would be a good addition to LabVIEW but the daylight saving time adjustment is simply a pitta to deal with no matter how you implement it. People seem to assume that it is a matter of knowing the two dates when switching happens and that this would be the same all over the world. It is not and to make things worse has been even a lot less in the past. Thus to know if a certain timestamp is DST or not you need to know also its geographical location and a database which changes almost with every year. I do believe that Windows for that matter doesn't even care about that other than adjusting DST for the current time zone based on fixed in information valid for the year of release of the Windows version or possibly Service Pack. If you would try to check a timestamp around 25 years ago in lets say Switzerland on a current Windows platform you would find out that it is easily off by one hour around the date the DST went into effect and again out of it as they and some other countries here didn't feel like using the same switching dates as the rest of Europe. At that time you could easily have three or more different DST periods in the same year in Europe alone. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
