Problem with description of Casting with optional mask from string to Time_Period/Duration and Time_Period/Duration to string

[javihern98]

Overview

Looking at the 2.2 spec, there seems to be some inconsistencies with the usual way of handling time formats:

Cast from String with optional mask

• Duration: ISO-8601 durations (P...) or shorthand (A, S, Q, M, W, D)
  • Example: "P1Y" → 1 year, "P3M" → 3 months, "A" → 1 year (annual), "Q" → 1 quarter
  • VTL 2.2 Spec:

    If the input string starts with P, the entire string is consumed and parsed, according to the ISO-8601 standard for durations up to a precision of days, and the corresponding duration value is returned. Otherwise, one of A, S, Q, M, W or D is consumed, and a duration value is returned representing the duration respectively of a year, a half of a year, a quarter of a year, a month, a week and a day.

Cast to String with optional mask

• Time Period: ISO-8601 time interval format start/end (day precision)

  • Format: YYYY-MM-DD/YYYY-MM-DD
  • Example: 2024-01-01/2024-12-31 (annual), 2024-01-01/2024-03-31 (quarterly)
  • Note: Represents the full period inclusively
  • VTL 2.2 Spec:

    the time_period value is printed using the ISO-8601 representation for generic time intervals, up to a precision of days, in the form start/end.

• Duration: ISO-8601 duration format starting with P

  • Format: P[n]Y[n]M[n]W[n]DT[n]H[n]M[n]S (only relevant fields included)
  • Example: P1Y (1 year), P3M (3 months), P7D (7 days), PT2H30M (2.5 hours)
  • VTL spec limits precision to days, so time components (hours/minutes/seconds) may not be used
  • VTL 2.2 Spec:

    the duration value is printed using the ISO-8601 representation for durations.

To review

• Explain why TimePeriod is written as a date interval with day precision, instead of the usual format (like 2020Q2)
• Normalisation of the use of hyphen or not in the Time_Period representation (whether to always use 2020-Q2 or 2020Q2 or 2020 instead of 2020A. We really need to be consistent in the whole manual with this
• Explain why Duration has in the to string as the ISO 8601 but the from string also includes the shorthand, we should always use ISO 8601 IMHO

[vpinna80]

Hi @javihern98,
As a reminder here's the original ratio behind the 2.2 spec.

1. "up to" means that you can stop at whichever precision the time period is expressed, you're not forced to go down to days. Also, the short notation isn't allowed without mask because some time periods cannot be represented, for example 2026-01/2026-04.
2. The hyphen is mandatory when using ISO, otherwise no hyphen is allowed. Also, the specification is for the VTL cast operator only. When you read from (write to) a file or read/print a manual page, you are not performing a VTL cast, but an external conversion: the VTL basic scalar type remains the original one, no changes in the manual are needed.
3. The short notation for duration is there to facilitate SDMX compatibility, where frequency is expressed with a single letter.

[javihern98]

Hi @vpinna80, the problem is therefore which is the "VTL basic scalar type representation", and whether we should be more consistent here regarding the Time_Period. It literally says on the cast from Time_Period to String:

the time_period value is printed using the ISO-8601 representation for generic time intervals, up to a precision of days, in the form start/end.

I believe this should be changed to something like "the Time_Period representation YYYYPppp, where YYYY is the Year, P is the Period indicator (as per the single character duration values) and ppp is the period number.

Finally, the use of the "Duration" term for both the ISO 8601 and single character duration values I find it very misleading. We should only use Duration as the ISO 8601 and make a default string Value Domain where these single characters may be used (like the Period Indicator or Timeshift operators), but using String Data type instead of Duration (this should be a separate issue)