Proposal: Unify ISO8601 terminal names

[ciozi137]

Various names are used:

• At minimum it is confusing (eg "ISO8601 Date String" may contain a time)
• Sometimes the label is incorrect ("ISO8601 UTC DateTime" often is not expressed UTC time)

Proposal:

• Rename the terminals "ISO8601 DateTime" [I think "ISO8601 Timestamp" is better but this suggests VI names like "ISO8601 Timestamp to Timestamp.vi"]
• Rename VIs while maintaining deprecated names:
  • ISO8601 DateString.vi --> ISO8601 DateTime to Timestamp.vi
  • Timestamp to ISO8601 UTC DateTime.vi --> Timestamp to ISO8601 DateTime.vi

[ciozi137]

@francois-normandin just did spot check and I am getting result shown below, but tests are otherwise passing...

[ciozi137]

Looks like it is not working if milliseconds are not present.

OK:

Not OK:

[francois-normandin]

That will need to be corrected. ISO standard supports it, but I assume it is not mandatory?

Can you check if it works with a non-strict validation?

https://www.iso.org/iso-8601-date-and-time-format.html#:~:text=Therefore%2C%20the%20order%20of%20the,minutes%2C%20seconds%2C%20and%20milliseconds.

[francois-normandin]

Deprecating ISO8601 UTC DateTime.vi

[francois-normandin]

@ciozi137 Can you review this pre-release package to see if I missed some spots?
I had to bypass your pull request because I made changes on top of your previous PR.

https://github.com/LabVIEW-Open-Source/Epoch-Time/releases/tag/1.3.0

[ciozi137]

Hi @francois-normandin happy new year! Been following your updates. Give me a day or two and I'll take a closer look

[ciozi137]

Hi @francois-normandin I'm not sure where to put this, but I'll add here. When I run 'ISO8601 String to Timestamp.vi', for strict? == T/F I get valid?==T without the 'T' separator. So I'm not sure what the meaning of 'valid?' is in this case.

Strict?==T:

Strict?==F:

[francois-normandin]

@ciozi137 good find. You see in your first image that it was detected as a valid time, but not a valid date-time.

I'll need to add a provision in the algorithm to be invalid in this case, whenever the second part is not valid. I would assume we can inspect the after-match string to make that determination.

[ciozi137]

@francois-normandin

1. do you mean valid date (not time) in first image?

2. New question:
   I'm concerned about the lack of symmetry in the following calculation:
   

Without the leading "T", ISO8601 TimeString to Timestamp.vi will not work if Strict ISO?==T. But Timestamp to ISO 8601.vi is outputting without the T...

[francois-normandin]

@ciozi137
1- yes indeed
2- yes, the logic needs to be tweaked to a form of AND, instead of OR statement whenever the strict flag is true.

I recommend we split the valid iso test vector file into a valid strict and valid non-strict file. Idem for invalid vector.

The ISO time is fine, it's the ISO string that needs to be tweaked to be consistent.

I'm not in front of my computer, but take a look at the logic in the ISO string VI... We should not allow matching as valid string if there is a residual time string that is not strictly ISO (with the prefix T).

[ciozi137]

I am unclear if "16:43:37.52Z" (without "T") is valid or invalid ISO8601. According to this site it is.

[francois-normandin]

It is invalid. It's RFC3339 valid, the predecessor of iso8601.

I prefer to use the actual iso8601 document as the source of truth