boolean expression only evaluates last element

[brymatm]

What did you do?
Created the following recording rule and included it in my alerts:

workhours=day_of_week() < BOOL 6 * hour() >= BOOL 13 * hour() < BOOL 22

What did you expect to see?
Did not expect to receive alerts outside of the specified hours.

What did you see instead? Under which circumstances?
At the time I wrote this, day_of_week() resolved to 3, hour() resolved to 11:

Received alerts outside of the specified hours for datafeeds undergoing nightly refreshes. When I manually input the expression in Prometheus I was surprised to see the expression returning 1 when the hour was less than 13. When I changed the order of the expression to this it returned 0 as expected:

day_of_week() < BOOL 6 * hour() < BOOL 22 * hour() >= BOOL 13

When I drop the expression to two elements and change it so that the day of week should cause the expression to fail, it still only evaluates the last element of the expression:

day_of_week() > BOOL 6  * hour() < BOOL 22

(see attached images)

Environment

• System information:

Linux 2.6.32-358.el6.x86_64 x86_64

• Prometheus version:

prometheus, version 1.3.0-beta.0 (branch: master, revision: 5273b55)
build user: root@cb83e777216a
build date: 20161020-08:51:20
go version: go1.7.1

• Alertmanager version:
• Prometheus configuration file:

workhours=day_of_week() < bool 6 * hour() >= bool 13 * hour() < bool 22

ALERT rateAlert_server_datafeed
  IF rate(server_datafeed[10m]) == 0 and on () workhours == 1
  LABELS { topic = "datafeed", }
  ANNOTATIONS {
    summary = "Topic datafeed on {{ $labels.job }} has not received a message for at least 10 minutes",
    subject = "No messages for topic datafeed on {{ $labels.job }}",
  }

• Alertmanager configuration file:
• Logs:

[brian-brazil]

• binds tighter than <=, see https://prometheus.io/docs/querying/operators/#binary-operator-precedence

Add parens to force evaluation order.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.