LabVIEW
Timestamp always converted to UTC?
Solved!
But the binary LabVIEW timestamp being a specific LabVIEW format, it seems unlikely that the other application is expecting exactly such a timestamp but translated into local time. Most likely, if it is even binary, it has a different time baseline too, and you need to do some offset calculations anyhow. In that case do the offset calculationis at the moment when you hand over a timestamp to that other application and leave the LabVIEW timestamp alone.
The LabVIEW controls and debug windows and just about anything else that presents the timestamp to a user don't display wrong times, they simply display local time for the system the timestamp is presented on. If your timezone for the actual runtime system doesn't match with the timezone of the system you look at a timestamp you do get "wrong" times, but the solution is not to manipulate the timestamp but to either match the timezone settings of both systems and if that is unpractical since one system is on the other side of the globe and both are in their respective location "correctly" setup, transmit the actual timezone offset with the timestamp and calculate whatever you need to have at the moment of display of a timestamp. Manipulating the timestamp directly only seems to solve your problem but in fact creates several others instead.
If there is another method to encode local time within LV for other applications that would be great. I will look forward to trying the method previously suggested.
The general consensus there is to use a string format. There are many standards how to do that, some of them even got their own IEC, ANSI and RFC numbers. It's not the most condensed form of transmitting timestamps, but it is certainly the most flexible one as such timestamps can contain meaninggful timezone information too. It's unfortunate that the LabVIEW developers didn't spare a byte of the 128 bits for storage of a timezone offset in the timestamp itself. The loss in accuracy would have been negligible but I'm sure there have been brainstorming sessions about that and there were several good reasons not to do so.
Time, and especially timezones, in terms of handling it in computers is a totally broken concept, but hey it's hard to change history after the fact. 
It would help to know what this other device was and why you think it requires a native LabVIEW timestamp but offset with the timezone offset. It seems unlikley that someone develops a device that expects a binary LabVIEW timestamp but with local time offset.
As to how devices handle time, that's a complicated issue. Allowing for timezone settings is a major complication of timehandling, so the more simple devices simply don't even allow for any timezone. They assume a linear calendar with no specific timezone at all. That means they use whatever time their real time clock is set to and it is the sole responsibility of the user to set this clock to whatever time he feels happy with. They don't really show UTC or CMT or whatever but simply time.
Usually that is local time in respect to the location the device gets configured for, since most users will simply set its internal time to whatever their watch shows at that moment, but strictly speaking it is not handling timezone at all and therefore also doesn't really have a concept of local time. In other situations this device may indeed be set to the time that corresponds to GMT because the organization uses many of those devices all over the globe and wants to be able to compare and correlate measurements from multiple locations in an easy way. The timezone of such a device is therefore not an inherent feature of the device itself but part of management of the organziation that uses the device.
Timezones complicating matters exponentially, this is the most easy implementation of time in resource constrained embedded devices. Anything else requires in fact a very complex (and error prone) timestamp handling and if you want to account for DST too which is almost mandatory when dealing with timzones already, then you have the additional problem of needing some way to update the DST periods for various locations on earth, since DST switch over dates and rules have traditionally changed a lot in the time since they were introduced and quite likely will keep changing in the future too.
The device is an embedded system and I have looked at the code running the controller. The comments in the code for the device state that it should accept a timestamp from LV or other device with same starting date.
So, I can guess that either the original LV code had an offset in it, or it was never needed to be accurate for the LV applications. I suppose I am just picky about things and would like it to be accurate.
So it's a LabVIEW Realtime system? Programmed in LabVIEW? That would explain a bit. The VxWorks based realtime systems at least and also the Pharlap based ones I believe don't really have a proper timezone handling. The timezone there is simply a user settable variable that determines a fixed timezone offset. No smart timezone handling at all on it. Have you checked in MAX what the timezone setting is for that device?
Also in older LabVIEW versions there were several bugs in respect to timestamps and timezone handling on the realtime systems.
