RE: Time zones and time stamps
Lewis Drake wrote: However, there is still an area where NI could improve the time plotting capability. When the plot span is greater than a few days, the major tic marks are placed on the UTC values for midnight (and multiples of midnight for spans of a month or so) rather than the values for midnight local time. This results in weird, non-intuitive, major tic mark values to mark day boundaries, such as 8:00:00 pm (i.e. EST for midnight). I've just found that in LV7 you can correct this using the property Xscale.Range.Start and setting it to your local midnight instead of 0. Jean-Pierre Drolet www.avensys.ca
RE: Time zones and time stamps
Speaking of Time zone and DST problems within LabVIEW... Has anyone noticed that some X vs. T plot Time scale labels are wrong in versions of LabVIEW prior to 7.0? When you make a time based plot of LabVIEW data, where the time span includes the time when DST (daylight savings time) changes to ST (standard time) or ST changes to DST? In the U.S. this occurs on the first Sunday morning in April (2:00am jumps to 3:00 am) and the last Sunday morning in October (3:00am goes to 2:00 am). This was a hard problem for NI to solve, but they finally did it in LV 7.0. However, there is still an area where NI could improve the time plotting capability. When the plot span is greater than a few days, the major tic marks are placed on the UTC values for midnight (and multiples of midnight for spans of a month or so) rather than the values for midnight local time. This results in weird, non-intuitive, major tic mark values to mark day boundaries, such as 8:00:00 pm (i.e. EST for midnight). A typical time plot for one of my process control oriented clients is a week or month long. This span presents an ugly time axis display and I've been asked to fix the problem several times. I'd like to see major tics for large time spans at midnight, week start, month start, year start... Maybe version 8.0 will have the fix? Lewis Drake Process Automation Corporation Belle Mead, NJ 908 359-1011 www.processauto.com
Re: Time zones and time stamps
Gary, I'm attaching (private email only) my collection of snippets from this forum concerning time zone corrections. -- Paul F. Sullivan SULLutions (781)769-6869 when a single discipline is not enough visit http://www.SULLutions.com
Re: Time zones and time stamps
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
RE: Time zones and time stamps
As both Rolf and George have pointed out, it would be great if you could request the timestamp to be formatted as UTC. I have run into this problem in two large projects, and it has frustrated me to know that LV keeps time in UTC, but I have to trick it into giving me the UTC value (by adding the offset). I encourage everyone to go to the ni.com Product Suggestion Center and request a similar feature. Jason Dunham SF Industrial Software, Inc. -- 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. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
RE: Time zones and time stamps
George Gatling wrote: All the same, the seconds to date/time provides a is DST flag... so there could still be a boolean input on the format to string function regarding whether to ignore the DST flag. Just a thought though. There could if it would be used at all!! The underlying Windows API functions most probably simply ignore this flag and so do probably all other system APIs including the Mac. Also note that the flag as returned from the seconds to date/time at least until LabVIEW 6.1, does not indicate the DST state of the timestamp entered in reference to the current DST switching times for the current time zone but the DST state of the current system time. As such it is highly useless or in fact even misleading. LabVIEW 7.0 fixed that to a certain amount, at least for the seconds to date/time function which seems to correctly indicate the daylight saving time flag in relation to the current locale and the actual time stamp converted. I say fixed it to some amount because the actual offset in seconds used is still in relation to the current timezone and DST of the current time. Consequently date/time to seconds blissfully ignores the DST flag completely and just simply uses the current time zones and times offset to convert a time cluster into a timestamp. This behaviour although somewhat strange and illogical is however highly desirable in terms of functional compatibility to earlier LabVIEW versions as many programs might suddenly misbehave if this had changed. Also note that the actual GMT delta library I mentioned earlier on downloadable from Developer Exchange has actually a problem when upgraded to LabVIEW 7.0 at least in the version I downloaded sometimes last year. It is not because of the change of above functions (which has not changed at all in this part) but because the hidden timestamp used as reference (Jan 1, 1980 0:00) gets modified when the VI is loaded into LabVIEW 7.0 by adding either the current DST offset or the current timezone offset (I'm not sure which one as they are both 1 hour for me at the moment) to it. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
RE: Time zones and time stamps
Alright, so then it would seem that the best solution would be to add an integer input to the format date time string function to specify offset from UTC... and to get UTC time you would wire a zero to this. To maintain backward compatibility, I still think the function should default to its current behavior if that terminal is unwired. This seems like a fairly trivial feature to implement since all the code for it should already exist... it would just need to be rearranged a little. And the consensus here on info-labview does seem to be a demand for such a feature. George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. --Jack Handy
Re: Time zones and time stamps
George Gatling (Contractor) wrote: Alright, so then it would seem that the best solution would be to add an integer input to the format date time string function to specify offset from UTC... and to get UTC time you would wire a zero to this. To maintain backward compatibility, I still think the function should default to its current behavior if that terminal is unwired. This seems like a fairly trivial feature to implement since all the code for it should already exist... it would just need to be rearranged a little. And the consensus here on info-labview does seem to be a demand for such a feature. yes, i'd love to see a VI with something like this... -- Timothy Wen Applied Physic Lab/U of W 1013 NE 40th St., Seattle, WA 98105 206-543-1300 (Voice)/543-6785 (Fax)
FW: Time zones and time stamps
-Original Message- From: Rolf Kalbermatter [mailto:[EMAIL PROTECTED] Sent: Tue, May 25, 2004 18:39 To: 'George Gatling (Contractor)' Subject: RE: Time zones and time stamps George Gatling (Contractor) [mailto:[EMAIL PROTECTED] wrote: Alright, so then it would seem that the best solution would be to add an integer input to the format date time string function to specify offset from UTC... and to get UTC time you would wire a zero to this. I was more thinking along the lines of adding an extra formatting specifier %^ or something like this to the beginning of the format string, which would say to format the time in UTC instead of local time. The advantage of this would be that in LabVIEW 7 the same formatting specifiers are also used in the advanced formatting settings for numeric and timestamp controls displaying absolute time/date. Maybe an extension of this would be %offset in seconds^ to use a specific time zone offset to use. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
RE: Time zones and time stamps
Hmm... not a bad solution either. And with no %^ the function would continue to use its existing behavior? At first I think it would be more convenient to specify offset in hours, but in the back of my mind I vaguely remember that there might be some places that use something really weird, like 30 minutes, for their daylight time... in which case I agree that seconds is the more consistent units to use when specifying the offset. At 12:39 PM 5/25/2004, you wrote: George Gatling (Contractor) [mailto:[EMAIL PROTECTED] wrote: Alright, so then it would seem that the best solution would be to add an integer input to the format date time string function to specify offset from UTC... and to get UTC time you would wire a zero to this. I was more thinking along the lines of adding an extra formatting specifier %^ or something like this to the beginning of the format string, which would say to format the time in UTC instead of local time. The advantage of this would be that in LabVIEW 7 the same formatting specifiers are also used in the advanced formatting settings for numeric and timestamp controls displaying absolute time/date. Maybe an extension of this would be %offset in seconds^ to use a specific time zone offset to use. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED] George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. --Jack Handy
RE: Time zones and time stamps
George Gatling (Contractor) [mailto:[EMAIL PROTECTED] Hmm... not a bad solution either. And with no %^ the function would continue to use its existing behavior? Yes, that is the idea without specific mentioning. Backwards compatibility is very important in such things. At first I think it would be more convenient to specify offset in hours, but in the back of my mind I vaguely remember that there might be some places that use something really weird, like 30 minutes, for their daylight time... in which case I agree that seconds is the more consistent units to use when specifying the offset. Exactly my idea. And it would not only be for DST adjustments but to display timestamps with a specific timezone offset which as I know for sure has even smaller adjustement requirements than 30 minutes. Rolf Kalbermatter CIT Engineering Nederland BVtel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijkhttp://www.citengineering.com Netherlands mailto:[EMAIL PROTECTED]
Re: Time zones and time stamps
George, 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. Thanks, Gary Subject: Re: Time zones and time stamps From: George Gatling (Contractor) [EMAIL PROTECTED] Date: Fri, 21 May 2004 17:34:33 -0400 Thanks guys for your feedback... I got a lot of replies that suggest ways I can manipulate the seconds counter in labview to get what i want, which will do the trick. It is not terribly complicated to adjust the seconds in the timestamp control (even accounting for daylight savings, if applicable) and then feed the adjusted value to the format date/time into string function. 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 timezone 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.
Re: Time zones and time stamps
George, In using the workarounds, you may find some VIs on my site handy, http://www.mooregoodideas.com/Downloads/Downloads.htm#DateTimeTools. Enjoy, --David Moore At 02:01 AM 2004-05-22 -0400, you wrote: Subject: Re: Time zones and time stamps From: George Gatling (Contractor) [EMAIL PROTECTED] Date: Fri, 21 May 2004 17:34:33 -0400 Thanks guys for your feedback... I got a lot of replies that suggest ways I can manipulate the seconds counter in labview to get what i want, which will do the trick. It is not terribly complicated to adjust the seconds in the timestamp control (even accounting for daylight savings, if applicable) and then feed the adjusted value to the format date/time into string function. However, this is IMHO still a workaround (one I intend on using though)... edited George - -W-H-E-A-T-W-H-E-E-L-L-E-N-S-T-O-W-I-N-D-O-W-I-N-G-G-P-R-O-G-R-A-M-W-E-B- - -- David A. Moore - Moore Good Ideas, Inc. -- -- (801) 773-3067 - NI Alliance Member -- -- 1996 Allison Way --- www.MooreGoodIdeas.com -- -- Syracuse, Utah 84075 - [EMAIL PROTECTED] -- -
Time zones and time stamps
The Get Date/Time in Seconds function returns a time stamp control that appears to contain the local date and time. Is there a way to convert this to UTC without doing a bunch of crazy tail math / logic? I mean, to do it correctly required a lot of thinking to account for daylight savings, leap seconds, and so on... I hope I am overlooking something very trivial. I would prefer to avoid having to make OS calls to query the local time zone, etc if possible. Our system clock is steered by a GPS time server, so the system time is fairly accurate, but for convenience is also in local time. However, we would rather use UTC for creating file names and for timestamps in the files to avoid possible conflicts surrounding the crossover to standard time. (Some of our processes are now 24/7 so this is something we have to consider. George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. --Jack Handy
Re: Time zones and time stamps
Thanks guys for your feedback... I got a lot of replies that suggest ways I can manipulate the seconds counter in labview to get what i want, which will do the trick. It is not terribly complicated to adjust the seconds in the timestamp control (even accounting for daylight savings, if applicable) and then feed the adjusted value to the format date/time into string function. 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 timezone 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. George At 02:55 PM 5/21/2004, you wrote: The Get Date/Time in Seconds function returns a time stamp control that appears to contain the local date and time. Is there a way to convert this to UTC without doing a bunch of crazy tail math / logic? I mean, to do it correctly required a lot of thinking to account for daylight savings, leap seconds, and so on... I hope I am overlooking something very trivial. I would prefer to avoid having to make OS calls to query the local time zone, etc if possible. Our system clock is steered by a GPS time server, so the system time is fairly accurate, but for convenience is also in local time. However, we would rather use UTC for creating file names and for timestamps in the files to avoid possible conflicts surrounding the crossover to standard time. (Some of our processes are now 24/7 so this is something we have to consider.) George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. --Jack Handy George Gatling Applied Technology Division, SFA Inc. Space Physics Simulation Chamber US Naval Research Laboratory 202-404-5405 (phone) 202-767-3553 (fax) If trees could scream, would we be so cavalier about cutting them down? We might, if they screamed all the time, for no good reason. --Jack Handy
