Timestamp to String Different Between RT and Windows

[Jeff Plotzke]

I'm using the 'Get Time/Date in Seconds' VI wired to a 'Format Into String' with "%T" as the format. I noticed that I get two different date/time strings depending if I do this on a Windows PC or on a PXI RT System:

Windows PC: 11:31:48.293 PM 3/16/2007

LVRT: 21:31:49.293 03/16/2007

These slight differences are messing with me since I'm trying to transfer this timestamp between a PC and RT system using format to string/scan from string.

So, my two questions:

1. Is there a way to set the locale settings in RT to tell it how to format a date/time string?

2. Should I not do this this way and instead use the 'Format Date/Time String' VI on the RT side to create a string like the Host expects. However, I'm still weary of the day if the locale setting of Windows gets changed. Then, my strings won't match up again.

What's the correct way to pass timestamps between systems without worrying about locale settings?

Thanks!

[Mikkel]

QUOTE(Jeff Plotzke @ Mar 16 2007, 05:38 AM)

What's the correct way to pass timestamps between systems without worrying about locale settings?

If you use 'Format Date/Time String' with the 'UTC format' set to true, the string output will be universal time (UT), and should be comparable between systems - but then you will not get 'real' time for your current location (unless of course your location is in the UT timezone).

-Mikkel

[tnt]

QUOTE(Jeff Plotzke @ Mar 16 2007, 05:38 AM)

I'm using the 'Get Time/Date in Seconds' VI wired to a 'Format Into String' with "%T" as the format. I noticed that I get two different date/time strings depending if I do this on a Windows PC or on a PXI RT System.

What's the correct way to pass timestamps between systems without worrying about locale settings?

Hi Jeff,

I'm not familiar with RT, but why don't you define your own timeformat on both PC and RT (and NOT using %T) ??

For writing to logfiles for example I always use a custom timestamp to be independant from local settings like AM/PM, day/month order, ...

http://forums.lavag.org/index.php?act=attach&type=post&id=5209''>http://forums.lavag.org/index.php?act=attach&type=post&id=5209'>http://forums.lavag.org/index.php?act=attach&type=post&id=5209

BTW, why don't you transfer the timestamp as a value (seconds in U32/DBL) in stead of as a string?

Good luck,

TNT

[LAVA 1.0 Content]

QUOTE(tnt @ Mar 16 2007, 06:26 AM)

transfer the timestamp as a value (seconds in U32/DBL) in stead of as a string

4 bytes instread of 21+ bytes, and no conversion overhead.... :thumbup:

[Grampa_of_Oliva_n_Eden]

QUOTE(LV Punk @ Mar 16 2007, 06:28 AM)

4 bytes instread of 21+ bytes, and no conversion overhead.... :thumbup:

Just transfering the time stamp as a number works fine. I have at least one application that has bee running at multiple sites for the last five years using that method. It also works across time time zones.

Added note: Avoid strings whenever possible on RT app that have to run forever. The can do very nasty things to your memory requirements.

Ben

[Jeff Plotzke]

QUOTE

BTW, why don't you transfer the timestamp as a value (seconds in U32/DBL) in stead of as a string?

QUOTE(LV Punk @ Mar 16 2007, 07:28 AM)

4 bytes instread of 21+ bytes, and no conversion overhead.... :thumbup:

Great suggestion -- Thanks all!

[Mike Ashe]

QUOTE(Ben @ Mar 16 2007, 07:28 AM)

Added note: Avoid strings whenever possible on RT app that have to run forever. The can do very nasty things to your memory requirements.

Ben, could you elaborate on "very nasty". I am using strings here and there in a new RT app and so far things are going okay, but it hasn't exactly been running "forever". What if you preallocate your strings and then copy in and out of those? Won't that prevent the memory manager from having to reallocate?

[Grampa_of_Oliva_n_Eden]

QUOTE(Mike Ashe @ Mar 16 2007, 04:43 PM)

...What if you preallocate your strings and then copy in and out of those? Won't that prevent the memory manager from having to reallocate?

I belive so.

The bottom line is watch you memory usage.

I had a customer that was crashing after a period of time. I revised the code to work in-place and it stopped crashing.It ran fine for months. The customer added a text field to the control cluster and when the recipe was large the RT target wolud eventually crash. Took the text stuff out. It worked fine again.

Another customer wanted to buffer events in the RT if the Windows app went down. This was implemented as a round robbin buffer and worked fine. Unfortunately I included the error cluster in the buffer entries. Provided the were no errors the app ran and ran. If a bunch of errors were encountered, the app would crash after running out of memory. I modified the code (after attempting many other things) such that the Source fields of the error sub-Cluster (that got stored in my round robbin buffer) was replaced with an empty string and the crashes went away.

What you optimally want to do ( going out on a limb here concidering the audience) is use all brown clusters. If you have to go pink, make sure the variable length buffer storage requirements are not changing. If they have to change, they change to smaller requirements.

Just sharing my RT battle scars.

Ben