Values

values are always part of the guide to writing queries docid\ zbj6atbbc9 s7nlsnwchh , and denote the specific thing you're searching for certain values are only compatible with particular fields on the guide to writing queries docid\ zbj6atbbc9 s7nlsnwchh for example, if the lhs is a number or currency, the rhs value cannot be text quickquery will always let you know if you accidentally mismatch types on the lhs and rhs text a value representing text is always enclosed in double quotes " , e g "some text" "some text" unless specifically stated in operators docid a6c2c3f2fw7ydjuvamvz , these values are case sensitive (i e "some text" "some text" is not the same as "some text" "some text" , "some text" "some text" , etc ) dropdowns when querying on a dropdown field, quickquery will automatically suggest the appropriate values other than that, they are identical to text values numbers numbers are entered as you would expect, e g 25 25 if you need a negative number, prefix it with , e g 25 25 you can also prefix numbers with an optional + , if you want to, e g +50 +50 for decimals, enter the fractional part after a period , e g 3 14 3 14 currencies when entering a currency, prefix the numerical value with the currency enclosed in double quotes " , e g "usd" 7000 "usd" 7000 be sure to include the space between the currency and the value the numerical value can be any valid number, e g "usd" 5 8 "usd" 5 8 any of the following can be used as the currency specifier the currency code, e g "usd" "usd" the currency symbol, e g "$" "$" full name of the currency, e g "us dollars" "us dollars" quickquery will always suggest all available currencies binary the available binary values are true true and false false you use them when searching by e g checkboxes \[ do not call do not call ] = = false false temporal there are two types of temporal values fixed and interpreted in both cases, time zone settings are respected fixed fixed values have a fixed form, and are entered exactly as seen here they involve the units second second minute minute , hour hour , day day , week week , month month , year year and can be any of the following now now today today this \<unit> this \<unit> , e g this hour this hour last \<unit> last \<unit> , e g last month last month next \<unit> next \<unit> , e g next year next year any combination of \<whole number> \<unit> \<whole number> \<unit> , e g 3 years 5 minutes 3 years 5 minutes the units must be sorted in descending order, i e 5 minutes 3 years 5 minutes 3 years is not allowed \[ date created date created ] = = today today all fixed values are converted to a time range therefore, the above query is actually translated to \[ date created date created ] = = <00 00 today>, <23 59 today> <00 00 today>, <23 59 today> this only happens with fixed temporal values, and not with interpreted temporal values interpreted interpreted values allow for a "free form" textual description of a temporal amount, such as next monday next monday , 7 weekdays 7 weekdays , first day of next month first day of next month etc interpreted values are surrounded by @\[] @\[] , e g @\[tomorrow 3pm] @\[tomorrow 3pm] the range of interpreted values is incredibly broad, and is documented in detail here technical details interpreted values are interpreted as a series of modifiers/commands which change the value, starting from the current date and time therefore, writing e g 7 weekdays 7 weekdays starts with the current date and time, and subtracts 7 weekdays from it the resulting value will be "now", but 7 week days ago as another example, writing first day of this month 13 00 first day of this month 13 00 starts with the current date and time, and first interprets "first day of this month", which changes the date appropriately it then interprets "13 00", which changes the time in practice, the easiest way to find out what they can do is to try them out read faq docid\ w qrkderlew3wrpt zmuc if you need help figuring out what a specific interpreted value translates to here's an example \[ date created date created ] strictly after strictly after @\[ @\[ tomorrow tomorrow 3pm] 3pm] interpreted temporal values are not converted to time ranges therefore, @\[ @\[ tomorrow tomorrow 3pm] 3pm] means tomorrow at exactly 15 00 00 down to the second when entering an interpreted value, be sure to enter the "more general" specifiers first, and the "more specific" ones later! as stated above, each part of an interpreted temporal value is translated to a command that modifies the date and time therefore, writing @\[tomorrow 3pm] @\[tomorrow 3pm] will first interpret "tomorrow" and set the value to "\<tomorrow date> \<current time>", and then it will interpret "3pm" and set the time value to 15 00 00 (while keeping tomorrow's date) however, writing @\[3pm tomorrow] @\[3pm tomorrow] will first interpret "3pm" and set the time value to 15 00 00, and then interpret "tomorrow" and set the value to "\<tomorrow date> \<current time>", which will overwrite the 3pm we entered earlier! fixed vs interpreted while interpreted values give you a much greater flexibility, they are not well suited when used with equality, because they represent an exact instant , and not a time range consider the following two queries \[ date created date created ] = = today today \[ date created date created ] = = @\[today] @\[today] the first involves a fixed temporal value, and will therefore be translated to " date created between 00 00 00 and 23 59 59 today ", which yields the query we probably meant the second query involves and interpreted temporal value, and is simply translated to " date created equals 00 00 00 today ", which will only display records which were created at exactly midnight today however, there's nothing preventing you from writing out the range yourself \[ date created date created ] between @\[today midnight] @\[today midnight] , @\[tomorrow midnight 1 seconds] @\[tomorrow midnight 1 seconds]