I don't think its as easy as choosing function A or function B to create the string. The important question to answer is what do we want to use the string for?
ISO-8601 is extremely flexible about precision and units. Ton gave the classic example that might be used in recording the basic date and time of an event. He used the UTC (Coordinated Universal Time) option of 8601.
A UTC string can only be created using the Format Date/Time String function because the native Format to String function has no flag or option for UTC.
There is no Scan from Date/Time String function, so we must break down the UTC string either into a date/time record cluster (yuck) or use the Scan from String function. Just as the Format to String function, there is no accounting for TZ or DST.
The solution is to convert the string to a local time stamp, convert that to a string using the Format Date/Time String with UTC format as TRUE, then convert that to a time stamp again. Subtract the last time stamp from the previous to determine the TZ / DST relative time and then subtract to get the true time. (see attached)
I personally include the seconds portion in my UTC timestamps. This simply requires adding a %S format specifier.
This brings up a question: What precision might someone want to record a timestamp value to? A LabVIEW timestamp is accurate to 0.05421010862427522170... attoseconds.
ISO 8601 does support fractional seconds. The spec is nice enough to support a comma or period as a separator between the whole and fractional part, but this is going to be one very long string if we write the full accuracy of the time stamp into the string.
I suspect that waveform timestamp data may need to be saved differently than a simple timestamp. Maybe as a cluster of I64 and U64? It typecasts nicely and the seconds (I64) part may be sufficient for the Format Variant to String.
ISO 8601 String Tests.vi