how to get UTC timestamp for deteriming start of new hour, day and month

[jmgleason]

I have a data logging application in which I want to produce archive records at the start of each "new" hour, day and month with statistics over the "previous" hour/day/month. I want the archive records to have timestamps that designate the start of data collection time period.  I use Get Date/Time in Seconds in my data collection loop, followed by Seconds to Date/Time and Unbundle by Name and I then detect loop iterations where the Unbundle outputs (hour, day of month, and month) change value. Problem is I "miss" an hour every fall at the daylight savings fall-back -- the Unbundle by Name hours output does not change at the fall-back hour. (Different but related artifacts occur at the spring-forward transition.) My issue would be easily resolved if Get Date/Time in Seconds had an option to output a timestamp in my local EST without daylight savings adjustments or to output UTC (which I could then offset for my timezone). Unfortunately, Get Date/Time in Seconds does not support those options. Would that not be an easy Labview modification?

     I've reviewed the many posts on the subject of "UTC timestamps" and I've experimented with every combination of "to UTC", "is UTC", "is DST" (0, 1, -1), display format editing, and computer system time display that I can think of but no success. I've seen some very thoughtful discussions on the subtleties of timestamps and the daylights savings impacts. BUT I have not been able to find an approach that would allow me to generate and operate on a UTC timestamp that is ALWAYS correct.

     Setting "to UTC" to T in Seconds to Date/Time, I can easily detect the hour transitions in my data loop, I think I can also work out the details of detecting and synchronizing the hour and month transitions and deriving the archive timestamps but my code would be much more straightforward if I could operate directly on a timestamp in standard time year-round.

     Any suggestions would be greatly appreciated.

[RTSLVU]

Try this

Notice the date time rec set to UTC has removed DST

[jmgleason]

Thanks. But I want to get to a UTC timestamp -- not a time record.  In my testing (by adding 60 second intervals inside a while loop) converting from a time record using Date/Time in Seconds did not resolve the daylight savings transition artifacts regardless of whether I set "is UTC" to T or F.

[RTSLVU]

You mean like this?

[Bob_Schor]

At the risk of really muddying the waters, the Good News is that the LabVIEW Time Stamp (the patterned brown wire) is in UTC format (assuming your PC is set to the correct Time Zone and country).  What the Time Functions do is to show you "human-readable" interpretations of this UTC Time, which they most often do in terms of the current Local Time.

Suppose you do an experiment, and write down the Start Time as a TimeStamp.  Suppose you start at noon the the day before DST starts, and finish at noon the next day.  [I'm probably going to get this backwards, but ...]  Since you turned your clock forward one hour, your experiment lasted only 23 hours.  If you took the two Time Stamps and fed them through Get Date/Time String, they would show the time as noon, yet if you subtracted them and showed the difference as a Time, it would be 23 hours (the correct answer).

Another useful function to play with and convince yourself that you can "trust" Time Stamps is Format Date/Time String, which has a UTC input.  The point I'm trying to make is that the value for Time that this function returns with UTC = True is the time value that is contained in the TimeStamp, itself, independent of your Time Zone.

Bob Schor

[JÞB]

Change the WINDOWS time setting to "(UTC) Universal coordinated time"  You'll miss leap seconds but you don't see them now anyway.

For a PC collecting data like you said you have, it probably should be set the UTC anyway.  Bonus: the code now even tavels well! since its the Windows setting that is really the source of the frustration you are trying to code arround.