[V3.1.3 Backport] fix(schema): align date/time operators with BNF; widen timeLiteralPattern#613
Conversation
…h/$year and timeLiteralPattern
The BNF defines these keys as numeric-extraction functions over a
dateTime expression:
<dateTimeToNum> ::=
( "$dayOfWeek" | "$dayOfMonth" | "$month" | "$year" )
<ws> "(" <ws> <dateTimeOperand> <ws> ")" <ws>
where <dateTimeOperand> is a DateTimeLiteral, a cast to dateTime, or
a GlobalAttribute (e.g. GLOBAL(UTCNOW)). The argument is therefore a
Value expression that evaluates to a dateTime, not a literal
xsd:dateTime string.
The JSON schemas typed these four keys as
$ref: "#/definitions/dateTimeLiteralPattern"
which forced them to be literal ISO date-time strings and made
constructs like `{"$dayOfWeek": {"$attribute": {"GLOBAL": "UTCNOW"}}}`
invalid even though the BNF explicitly allows them.
timeLiteralPattern was also stricter than the grammar: it rejected
fractional seconds. The BNF <time> is:
<hour> ":" <minute> ( ":" <second> )? ( "." <fraction> )?
Changes:
- $dayOfWeek, $dayOfMonth, $month, $year -> $ref Value
- timeLiteralPattern pattern
before: ^[0-9][0-9]:[0-9][0-9](:[0-9][0-9])?$
after : ^[0-9]{2}:[0-9]{2}(:[0-9]{2})?(\.[0-9]+)?$
Files:
- aas-specs-api: partials/query-json-schema.json, pages/schema.adoc
- aas-specs-security: partials/json/aas-queries-and-access-rules-schema.json, partials/json/formulas-and-logical-expressions.json
Refs: Review Finding T-14
Made-with: Cursor
| }, | ||
| "$dayOfWeek": { | ||
| "$ref": "#/definitions/dateTimeLiteralPattern" | ||
| "$ref": "#/definitions/Value" |
There was a problem hiding this comment.
Why is it Value and not just string? Same question for all date related fields
There was a problem hiding this comment.
TF API (17.06.2026): Indeed, this actually should define it as JSON "integer". Same for the others, see comment below.
|
|
||
| Minor Changes: | ||
|
|
||
| * fix: Aligned date/time extraction functions (`$dayOfWeek`, `$dayOfMonth`, `$month`, `$year`) in JSON Schema to accept all `dateTimeOperand` types per BNF grammar, and widened `timeLiteralPattern` to support fractional seconds. |
There was a problem hiding this comment.
why do we need fractional seconds?
Martin187187
left a comment
There was a problem hiding this comment.
In my opinion $dayOfWeek, $dayOfMonth, $month, and $year should be integer.
TF API (17.06.2026): The group in general agrees that integer for $dayOfMonth, $month, and $year makes sense. In compliance with ISO 8601, also $dayOfWeek shall be an integer with |
Actually $dayOfWeek, $dayOfMonth, $month, and $year are functions and input should be Value (or more detailed $dateTimeVal or $atribute parameters). So it takes Value (or more detailed $dateTimeVal or $atribute parameters) and returns an integer. So the current version is correct. But maybe we should introduce a new object that combines $dateTimeVal and $atribute? This would be even more correct. |
|
TF API (17.06.2026): Previous comments were based on a wrong interpretation of the JSON schema structure, thanks @Martin187187 for pointing that out. Still open question: Is it really required to go the "all-included" |
Backport from PR #582
This is a backport of the bugfix from PR #582 to the V3.1.3 release branch.
Original PR Description
This PR aligns JSON schemas with the BNF grammar for date and time semantics in the AAS Query Language.
Problem:
$dayOfWeek,$dayOfMonth,$month, and$yearas numeric extraction functions accepting adateTimeOperand(literal, cast, or attribute access). However, the schema restricted these todateTimeLiteralPattern, rejecting valid constructs like{"$dayOfWeek": {"$attribute": {"GLOBAL": "UTCNOW"}}}.timeLiteralPatterndidn't support fractional seconds despite the BNF allowing them.Solution:
#/definitions/Valueinstead of literal patternstimeLiteralPatternregex to permit optional seconds and fractional components:^[0-9]{2}:[0-9]{2}(:[0-9]{2})?(\.[0-9]+)?$Related