Format Date/Time to String -3 Hours offset to Windows System time

[rolfk]

---

@tbd wrote:

Hi Markus,

      It's concievable you may find this VI useful.  It decomposes LabVIEW time (seconds since 1/1/1904) Year, Month, Day, etc.  It's useful for building timestamps that are independent of LabVIEW's timestamp functions.  Note, however, no attempt is made to accommodate DST shifts!

---

It has a fundamental problem too. Your "Error correction" is not right. You adjust in fact for your local timezone since the LabVIEW timestamp is defined to be in relation to Midnight on January 1, 1904 Universal Time, or abbreviated UTC. Without your "Error Correction" you get the actual date and time in UTC.

Your function gives for my current location and time July 6, 2006, 23:52.17 while I have July 7, 2006, 9:52.17 and that is at UTC + 2 hours. Basically you seem to have programmed this VI in UTC -8 which I guess is Pacific Time, No Daylight Saving Time.

As you can see time in computer programs can be a complicated matter! 😉

Rolf Kalbermatter

[tbd]

> It has a fundamental problem too. Your "Error correction" is not right.

> You adjust in fact for your local timezone since the LabVIEW timestamp is defined

> to be in relation to Midnight on January 1, 1904 Universal Time, or abbreviated UTC.

> Without your "Error Correction" you get the actual date and time in UTC.

Awsome, Rolfk - sincere thanks for this observation.

The, uh, "Error Correction" is now a configurabe GMT-offset so it'll work anywhere, ...anytime.  

Of course, its purpose is to ignore DST - to avoid having timestamps that suddenly jump forward or backward by an hour.