Values

14 min

values are always part of the rhs docid\ zbj6atbbc9 s7nlsnwchh , and denote the specific thing you're searching for certain values are only compatible with particular fields on the lhs 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"\ unless specifically stated in the documentation on operators docid a6c2c3f2fw7ydjuvamvz , these values are case sensitive (i e \"some text"\ is not the same as \"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\ if you need a negative number, prefix it with , e g \ 25\ you can also prefix numbers with an optional + , if you want to, e g \+50\ for decimals, enter the fractional part after a period , e g \3 14\ currencies when entering a currency, prefix the numerical value with the currency enclosed in double quotes " , e g \"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\ any of the following can be used as the currency specifier the currency code, e g \"usd"\ the currency symbol, e g \"$"\ full name of the currency, e g \"us dollars"\ quickquery will always suggest all available currencies binary the available binary values are \true\ and \false\ you use them when searching by e g checkboxes \[ \do not call\ ] \=\ \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\ \minute\ , \hour\ , \day\ , \week\ , \month\ , \year\ and can be any of the following \now\ \today\ \this \<unit\>\ , e g \this hour\ \last \<unit\>\ , e g \last month\ \next \<unit\>\ , e g \next year\ any combination of \\<whole number\> \<unit\>\ , e g \3 years 5 minutes\ the units must be sorted in descending order, i e \5 minutes 3 years\ is not allowed \[ \date created\ ] \=\ \today\ all fixed values are converted to a time range therefore, the above query is actually translated to \[ \date created\ ] \=\ \\<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\ , \ 7 weekdays\ , \first day of next month\ etc interpreted values are surrounded by \@\[]\ , e g \@\[tomorrow 3pm]\ the range of interpreted values is incredibly broad, and is documented in detail here https //www php net/manual/en/datetime formats php 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\ 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\ 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 this docid\ w qrkderlew3wrpt zmuc if you need help figuring out what a specific interpreted value translates to here's an example \[ \date created\ ] \strictly after\ \@\[\ \tomorrow \ \3pm]\ interpreted temporal values are not converted to time ranges therefore, \@\[\ \tomorrow \ \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]\ 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]\ 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\ ] \=\ \today \ \[ \date created\ ] \=\ \@\[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\ ] between \@\[today midnight]\ , \@\[tomorrow midnight 1 seconds]\