Time Conversion from Local to UTC Help! - Daylight Savings Problem?

[n3v1n]

Hi,

I am trying to use the generic conversion of local time to UTC time.  I thought I had everything working since I use the "Get Date/Time in Seconds" and then convert to "Seconds to Date/Time" witht the "to UTC" flag set true.  Then I convert back to a timestamp.

I thought I had everything working until I hit Daylight Savings for the Pacific Standard Time.  Now the Labview is off by 1 hour!

Is there an update to the Subvi's that do this?  Is this a known error?  Please help.   Thank you!

[smercurio_fc]

Your code is inconsistent. You wired a True to the Seconds to Date/Time function, but left the Date/Time to Seconds unwired, which defaults to False.

[n3v1n]

HI smercurio_fc,

Thanks for looking at this, but the inconsistency that you describe is intentional so that I convert the current time to UTC time in the first conversion.  If I were to put TRUE for the second conversion, it would convert back to Local time instead of UTC.  So my question still remains...

Oh btw, if you put an indicator after the first conversion, you'll get a "date time rec" cluster and notice that the DST = 0, meaning that Labview has the wrong Daylight Savings Time hardcoded into their subvi.

Thanks again.

[RavensFan]

I don't know exactly what you want your output to be.

But I don't see any issues with LabVIEW time.  I think you are doing a lot of manipulation back and forth through the date time record and lying to it about that is UTC and not.  You are giving that first conversion a time stamp and then telling the converter it is UTC.  So you get the timestamp record that says DST=0, because the UTC standard never adjusts for daylight savings time.

You can change the display format of your time stamp indicators to show UTC if you want by adding a carat ^ to the format specifier.

[n3v1n]

That is really interesting.  So your trick with changing the properties of the "Current Date/Time" using the property editor and adding the "^" - carrot symbol to do the conversion works.  Take a look at my code and screen shots.

This is a weird bug in the other Labview functions, but it looks like Raven found a solution.

Thank you,

[smercurio_fc]

I still don't understand what you think this bug is that you keep referring to.

[n3v1n]

I suppose it's not a bug after all.  Apparently I just didn't understand how the "Date/Time to Seconds" function and the UTC Flag worked.  I think the criticial take-away for me in this is the use of the "^" - carat symbol. 

Thank you all.

[RavensFan]

Here is the path you are doing that is causing the logic to fall apart for you.

1.  You are getting the current time.  In your images, it is 12:41 pm PDT which is 7:41 pm GMT

2.  You are asking for the date/time record (that cluster that breaks out everything) but are saying it is UTC, so you get a date/time record that 19:41 UTC (7:41 pm).  And the DST flag is 0.  (Because UTC doesn't observe daylight savings time.)

3.  Now  you are taking that date/time record and converting back to an actual date/time.  You don't wire up the UTC flag so it defaults to false.  Thus the date/time record is interpreted as local.  That DST flag is still 0 in your cluster.  So you are actually converting the time to 7:41 pm PST, which is actually 8:41 PDT.  (+1 hour for spring forward based on the month/date info.)

4.  You are displaying that time stamp in the indicator labelled "Current Date/Time (UTC)", but it is not truly UTC, it is actually the conversion of a local time from PST to PDT, and it is not even the current local time.  It is actually a "local" time 8 hours into the future.  If you put the carat into that indicator's display format, you'll see that the UTC time is in the future as well.  You call it UTC, but you are displaying a future local time.

The inconsistent conversions from local to UTC, and not accounting for the change of the DST flag from daylight time to UTC are what is confusing you.  You kind of get lucky during standard time because the DST flag is 0 for both local standard time and UTC.  But the conversions are still wrong, but it is a case of two wrongs are making it look right.  Even in standard time your input timestamp and your output timestamp indicator don't match which you would see if you used an Equals? function on them.

[n3v1n]

Thank you for that detailed explanation.  This really helps my understanding.