06-06-2023 07:30 AM
@rolfk wrote:
@billko wrote:Granted, but the original text in question does not contain this.
That’’s true, which requires one to make some assumptions. It is pretty safe to assume that such timestamps are in local time, the question of course is in which local time. CMT, EDT, EST or any of the other several dozen possibilities?
And do you really care? Let’s assume you got an isolated weather data set recorded at 13:37 in Tokio/Japan. Do you care if it was actually around midnight at your own location when that measurement was taken? Probably not, so it would be safe to treat the according timestamp simply as is and know that the measurements were taken after noon at the actual location.
But if it is an atmospheric measurement for instance, it may be useful to relate it to other measurements such as sun activity or similar and then you want to have an absolute universal coordinated timestamp. It may still be displayed in local time (the default for a LabVIEW timestamp control) but the underlaying timestamp is stored as UTC. And when converting external formats (ISO or not ISO) to a LabVIEW timestamp you have to consider these things.
That's what I was getting at. "Considering those things" is not a trivial matter. I wouldn't be sad if the world were to convert to UTC and do away with local time entirely.
06-06-2023 08:11 AM
@PhillipBrooks wrote:
See my signature...
Dang you beat me to it, that's what I was going to reply with. The correct answer is the first one with Scan From String, but the other information given about time zones, DST, and other time idiosyncrasies should be considered.
Unofficial Forum Rules and Guidelines
Get going with G! - LabVIEW Wiki.
17 Part Blog on Automotive CAN bus. - Hooovahh - LabVIEW Overlord
06-06-2023 08:17 AM
@billko wrote:
That's what I was getting at. "Considering those things" is not a trivial matter. I wouldn't be sad if the world were to convert to UTC and do away with local time entirely.
Not really sure where you live. I could actually live with that 😁 (with only 1 or 2 hours time difference to the current situation). But for many people it would mean to go to bed at 14:00 and get up at 22:00 to go to work (or something along that line) 😂
06-06-2023 09:50 AM
@rolfk wrote:
@billko wrote:
That's what I was getting at. "Considering those things" is not a trivial matter. I wouldn't be sad if the world were to convert to UTC and do away with local time entirely.
Not really sure where you live. I could actually live with that 😁 (with only 1 or 2 hours time difference to the current situation). But for many people it would mean to go to bed at 14:00 and get up at 22:00 to go to work (or something along that line) 😂
I'm -5 UTC, but whatever time you call it, wake-up time is still too early! 😄
06-06-2023 10:18 AM
I love Scan from String and Format into String. But there is a perfectly good "Format Date/Time String" that takes a LabVIEW TimeStamp as input and outputs a String where Date and Time are formatted as the User requests (with the default being %c, the "locale-specific default date and time"). It even has a Boolean input called "UTC" that does who-knows-what ...
Bob Schor
06-07-2023 09:45 AM
@mshaska wrote:
How do I format 03-31-23 15:44 into a time stamp format?
Something like %<dd-mm-YY HH:MM>T
06-08-2023 03:08 AM - edited 06-08-2023 03:09 AM
06-08-2023 06:12 AM
To scan UTC time from a string, e.g. 2023-06-07T14:30Z:
Use format string: %^<%Y-%m-%dT%H:%M:%SZ>T
To scan local time from string, e.g. 2023-06-07T15:30
Use format string: %^<%Y-%m-%dT%H:%M:%S>T
To format in to string, same as above
When viewing the time-stamp in LabVIEW the time displayed is in local time! it is not the actual value. The time-stamp internally is stored as the number of seconds since 1904-01-01T00:00. The time zone setting and 'adjust for daylight saving hours', therefore only effects format into string and scan from string, when local time is specified.
06-09-2023 02:05 AM
@sparkymark567 wrote:
To scan UTC time from a string, e.g. 2023-06-07T14:30Z:
Use format string: %^<%Y-%m-%dT%H:%M:%SZ>T
To scan local time from string, e.g. 2023-06-07T15:30
Use format string: %^<%Y-%m-%dT%H:%M:%S>TTo format in to string, same as above
I think the ^ shouldn't be in the local string...
06-09-2023 02:41 AM - edited 06-09-2023 02:49 AM
Sorry that was a copy and paste error, I believe you are correct:
I also didn't include seconds in my example strings.
To scan or format UTC time: 2023-02-17T16:20:00Z
the format string should be: %^<%Y-%m-%dT%H:%M:%SZ>T
For local time: 2023-02-17T17:20:00
the format string would be: %<%Y-%m-%dT%H:%M:%S>T