Defining Test Vectors

[francois-normandin]

This ticket will be for discussion about test vectors to be included for Epoch library.

@ciozi137 After review, the Venn diagram represents very well the state of the standard, although we are not supporting intervals and durations, nor mutual agreements.

Our Test Vectors should reflect the following situation:

[francois-normandin]

1. ISO8601 STRICT will be the Blue circle only
2. ISO8601 NON-STRICT will be the sum of Blue and Magenta circles.

RFC3339 is what Epoch 1.2 was with the non-strict flag, because it did not accept date-time with Weeks or Ordinal Days, so by changing Epoch library we cannot equate RFC3339 to be the same as ISO8601 with Strict = false anymore. We will need to have dedicated functions for RFC3339.

[francois-normandin]

I will submit that the following "ambiguous" ISO8601 entries be moved to Strictly valid test vector:

12:43:37-04:00
12:43:37.5-04:00
12:43:37.52-04:00
12:43:37.520-04:00
12:43:37.520300-04:00

16:43:37Z
16:43:37.5Z
16:43:37.52Z
16:43:37.520Z
16:43:37.520300Z

16:43:37+00:00
16:43:37.5+00:00
16:43:37.520+00:00
16:43:37.520300+00:00

16:43Z
16:43,6Z
16:43.6Z
16:43:37,520Z
16:43:37,520300Z

12:43-04
12:43,6-04
12:43.6-04
12:43:37-04
12:43:37.5-04
12:43:37.52-04
12:43:37,520-04
12:43:37.520-04
12:43:37,520300-04
12:43:37.520300-04

12:43-04:00
12:43,6-04:00
12:43.6-04:00
12:43:37,520-04:00
12:43:37,520300-04:00

16Z
16,7Z
16.7Z

12:43
12:43,6
12:43.6
12:43:37
12:43:37.5
12:43:37.52
12:43:37,520
12:43:37.520
12:43:37,520300
12:43:37.520300

12-04
12,7-04
12.7-04
12-04:00
12,7-04:00
12.7-04:00

[francois-normandin]

As for the time strings without colon, these cannot be ambiguous, so they have to be rejected until we have a mean to provide the developer/user with a mutual agreement strategy:

• 1243 can be both the year 1243 or the 12:43 local time.
• 124337 seems unambiguous as 12:43:37 local time, but 202410 could be Oct 2024 or 20:24:10 local time

1243Z is unambiguous because of the timezone designator, so I will move it to valid iso
I submit that the following tests be moved from ambiguous to valid ISO:

1643Z
1643,6Z
1643.6Z
164337Z
164337.5Z
164337.52Z
164337,520Z
164337.520Z
164337,520300Z
164337.520300Z
1243,6-04
1243.6-04
124337-04
124337.5-04
124337.52-04
124337,520-04
124337.520-04
124337,520300-04
124337.520300-04
12-0400
12,7-0400
12.7-0400
1243-0400
1243,6-0400
1243.6-0400
124337-0400
124337.5-0400
124337.52-0400
124337,520-0400
124337.520-0400
124337,520300-0400
124337.520300-0400

[ciozi137]

@francois-normandin thanks for the Venn diagram summary - it looks great.

Regarding arbitrary years (202, 20), LabVIEW only recognizes timestamps between the years 1600 and 9999, so I'm not sure there is a need to support 1,2,3 or 5 digit years? You have 2025 highlighted, but is that ambiguous?

[francois-normandin]

2025 or 20:25 without colon?
I honestly don't know how it can really be accepted unless we contextualize and limit only to ISO year or ISO time node.

As a generic ISO string, it is definitely ambiguous

[ciozi137]

Oops on my interpretation of 2 digit years - 20 refers to the century.

Regarding 2025 I was referring to this part of the diagram:

I'm scouring the spec for any guidance about lifting this degeneracy.

202 seems to only be allowed in an expanded representation by mutual agreement

[francois-normandin]

202 actually means the 2nd decade in the 20th century... No way we can support this without class based strategies. Let's drop

[francois-normandin]

2025 is meant to only resolve to "year 2025", but that's kind of a weird corner case for labview timestamp since it would need to be cast to jan1 at midnight, local time.
Not very useful.

We do not have a ISO year to timestamp anyway.
We have the timestamp to ISO year, which means we actually support it, but not in the part to cast to a LV timestamp. I'm fine with this.

[ciozi137]

Good news I think: 6 digit dates are not allowed without a separator:
202501 is not valid date. Would need to be 2025-01. So 202501 would default to 20:25:01

2025 is meant to only resolve to "year 2025", but that's kind of a weird corner case

Yeah I'm not trying to die on any hills here haha

[ciozi137]

Only remaining degeneracies (?):
YYYY with hhmm
YY with hh

These can be lifted via methods "Date String to Timestamp" and "Time String to Timestamp"

Generic "String to Timestamp" can reject as ambiguous

[ciozi137]

and/or require presence or absence of [T] for 2 and 4 digit strings

[ciozi137]

202 actually means the 2nd decade in the 20th century... No way we can support this without class based strategies. Let's drop

Just saw this. My reading of the spec is that 3 digit date isn't allowed. Either way - let's drop it!

[ciozi137]

All above I'm referring to ISO8601-2016

[ciozi137]

https://github.com/LabVIEW-Open-Source/Epoch-Time/blob/98ac3519dea6357071d221caa42bd0f5b280d162/tests/ambiguous-iso8601.txt

2024
202410**
1243
1243,6***
1243.6***
124337**
124337.5**
124337.52**
124337,520**
124337.520**
124337,520300**
124337.520300**

Comments:

** not ambiguous because 6 digit date is not allowed without a separator.
*** with decimal separator are also unambiguous?