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 BV    tel: +31 (070) 415 9190
Treubstraat 7H                  fax: +31 (070) 415 9191
2288 EG Rijswijk        http://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






Reply via email to