Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Unintuitive interpretation of some interval operator phrases

See original GitHub issue

There is an ambiguity in the specification related to the interpretation of timing relationships. Specifically, given this example:

define Interval1: Interval[@2012-01-01T09:00:00.0, @2012-01-01T10:30:00.0]
define Interval2: Interval[@2012-01-01T11:00:00.0, @2012-01-01T18:00:00.0]
define Within1: Interval1 ends 1 hour or less before start of Interval2

The specification implies in the definition of timing relationships ( that this should return true, but then describes in that it should be interpreted as a duration between that would return false.

The problem is that there are two boundaries involved in the comparison “X 1 hour or less before Y”:

  1. The boundary specified by the “before”, which is exclusive by the definition of the “before” operator.
  2. The boundary specified by the relative qualifier, “1 hour or less”, which is clearly inclusive.

In this particular case, those boundaries meet and so the interpretation is ambiguous. (In the case of “1 hour or more” the boundaries don’t meet, so there is no ambiguity and you get the intuitive behavior).

The translator should be updated to provide the intuitively correct behavior by having the inclusive boundary of the relative qualifier override the exclusive boundary of the comparison operator.

An STU comment has been submitted to the specification to clarify the ambiguity:

Issue Analytics

  • State:closed
  • Created 6 years ago
  • Comments:15 (15 by maintainers)

github_iconTop GitHub Comments

brynrhodescommented, Apr 27, 2017

Yes, that’s what I was thinking, and the in formulation is just a shorthand for the equivalent comparisons.

brynrhodescommented, Jun 1, 2017

CDS WG and measure developers all agreed with the change and it was approved as STU comment 1337 on Wednesday’s call. The change has been applied to the specification and the translator.

Read more comments on GitHub >

github_iconTop Results From Across the Web

How To Work with Dates and Times in SQL
In this tutorial, you will learn how to use dates and times in SQL. You'll begin by performing arithmetic and using various functions...
Read more >
Overview of the SQL LIKE Operator
This article explores the use of SQL LIKE operator using regular expressions to find and/or manipulate text.
Read more >
Ranges and indices - C# 8.0 draft specifications
This feature specification describes the syntax for ranges and indices, which support indexing individual elements of a sequence or a range ...
Read more >
C++ Mathematical Expression Library (ExprTk)
Optimization of expressions (constant folding, strength reduction, operator coupling, special functions and dead code elimination)
Read more >
1 Introduction
interpretation. Graphical Interval Logic (GIL) is a visual temporal logic in which formulas resemble the informal. timing diagrams familiar to designers of ...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Post

No results found

github_iconTop Related Hashnode Post

No results found