03-12-2024 02:16 PM - edited 03-12-2024 02:24 PM
Hi Bob,
I made those From/To ISO8601 functions on my own, supporting my needs…
I can handle the most typical ISO8601 timestamp of YYYY-MM-DDTHH:MM:SS.uuuu(Z|±HH:MM).
And I use those functions in ALL places where I need to store timestamps as strings…
(I needed them because I had to analyze test data written by my testbench software at a testbench located about 8 timezones from me.And there were colleagues trying to write measurement data over the weekend when DST started/ended, so the timezone indication at the end was VERY handy.)
It looks like this when German/European DST starts at last Sunday in March:
(same code as before)
03-12-2024 02:42 PM
@JHess wrote:
Hi Bob, I believe Andrey is right. I tried using the DST feature in the "Date/Time to Seconds" and got the same result. I also tried disabling the "Adjust for daylight saving time automatically" on my PC thinking maybe LabView uses the system clock but that didn't help either. This seems like it should be a simple thing to do but I am just stumped. I really appreciate the ideas/help from all of you.
I don't remember exactly and it might change between labview versions: Labview caches the time zone offset. When changing the PC time zone, you should also restart labview.
You display the time in local time, not in UTC. You need to change the display format to UTC and handle the time-zone offset (and maybe also the DST) by yourself. I remember that there are some text files in the wild www with all needed information about time zone offsets and DST information for all time zones of the known world.
03-12-2024 02:59 PM
Thanks Martin for the info regarding LabView and PC time. I disabled "Adjust for daylight saving time automatically" on my PC and restarted LabView. This fixed my problem so at least I have a workaround for the time being. This will buy me a little time to investigate this further.
03-12-2024 06:26 PM
@JHess wrote:
Thanks Martin for the info regarding LabView and PC time. I disabled "Adjust for daylight saving time automatically" on my PC and restarted LabView. This fixed my problem so at least I have a workaround for the time being. This will buy me a little time to investigate this further.
Pretty intrusive workaround, I would say.
03-13-2024 07:28 AM
Here is the URL that takes you to an announcement of "Epoch Date & Time by G Open Source Project for LabVIEW" (which, of course, I looked for in VIPM under "OpenG", but it is "G Open" ...). Icons seem similar to Gerd's -- whether or not this "solves" the confusing issues with Time I'll leave to braver explorers than I. So confusing ...
Bob Schor
03-18-2024 07:19 AM - edited 03-18-2024 07:21 AM
Years ago I discovered there is a specific format specifier for scan from string and format into string that will evaluate the data as UTC.
The secret is in the ^ (carat) at the beginning. See my signature below...
03-22-2024 10:57 AM - edited 03-22-2024 11:09 AM
This thread has helped me for a similar problem, except I wanted the DST adjustment.
For your problem to convert the time from UTC without any DST adjustment is straightforward. The GPower library available on VIPM has a get System Timezones Function with UTC Offsets. The offsets are not DST dependent. You can just use those offsets to determine the UTC difference without any DST adjustments. The meat of the VI needed is shown below. (Copyright GPower.)
For my problem, the solution was a bit more Rube-Goldberg, there has to be a better way. I wanted to convert a UTC timestamp to any timezone. If that timezone had DST, then I wanted that included. Below is my Rube solution.
EDIT: If you want to convert the time record to a timestamp, be sure to do this.