Qore Programming Language Reference Manual 1.19.2
|
The following are the basic data types in Qore (see Container Data Types and Code Data Types):
Basic Data Types
Type | Description | Example | Default Value |
Boolean | True or False value | True | False |
String | A sequence of characters with a character encoding | "string" | Empty string (i.e. "" ) |
Integer | A 64-bit signed integer | 1 | 0 |
Float | A double-precision floating-point number | 1.00023 | 0.0 |
Number | An arbitrary-precision number | 5.23928173726123e50n | 0.0n |
Date | absolute (with an associated time zone) or relative date/time values, both with resolution to the microsecond | 2010-05-10T18:35 :21.001456-07:00 | 1970-01-01Z |
Binary | An opaque binary object | <23deadbeef> | an empty object of size 0 |
NULL | Corresponds to a NULL value in a database query (not equivalent to NOTHING | NULL | NULL |
NOTHING | Represents the state of a variable having no value or function returning no value (not equivalent to NULL) | NOTHING | NOTHING |
"bool"
The keyword True stands
for the boolean value true.
The keyword False stands
for the boolean value false.
QORE_CHARSET
or the LANG
environment variable (see Environment Variables). If neither of these variables is set, then all strings will be assumed to have UTF-8
encoding."this is a string"
"string"
100
"integer"
-500.494
2.35e10
"float"
"n"
to it, designating a "number" value.-500.494n
2.35e10n
"number"
2012-02-17T19:05:54+01:00
"date"
Absolute date/time values specify a specific point in time in a certain time zone, such as January 1, 2005 10:35:00 +01:00. They are stored interally as a 64-bit signed offset from the Qore epoch (1970-01-01Z
), a non-negative 4-byte integer for microseconds, and a pointer to a time zone description object that provides the UTC offset and daylight savings time information (see Time Zone Handling for more information). Note that all absolute date/time values in Qore are stored internally in UTC and are converted for display purposes to the representation of wall time in their tagged time zone.
Absolute date/time values can be specified with a syntax based on ISO-8601 date formats as follows:
YYYY-MM-DD[THH:mm:SS[.n*]][Z|[+-]HH[:mm[:SS]]]
Note that if no time zone information is given, the local time zone will be assumed. If a time zone UTC offset is given, it is given in units of time east of UTC (i.e. +05
:00 means five hours east of UTC).
Or an alternative format (with a '-'
instead of a 'T'
to separate the time component):
YYYY-MM-DD[-HH:mm:SS[.n*]][Z|[+-]HH[:mm[:SS]]]
for example, for just the date without a time component (assumed to be midnight on the given date in the local time zone):
2010-05-26
for just the date in UTC, without a time component:
2010-05-26Z
or, for just the time, without a date component (note that in this case the date component will be set to Jan 1, 1970, in order for time arithmetic to function properly and will also be tagged with the local time zone):
20:05:10.458342
Some further examples (note that the date/time values without a time zone specification here are tagged with the local time zone):
The year must be a four-digit number, and all other values except microseconds must be two-digit numbers. If microseconds are present, at least one and up to 6 digits may be given after the decimal point. Pad the numbers with leading zeros if the numbers are smaller than the required number of digits. The hour component must be in 24-hour time format. Except for the month and day values, all other values start with 0 (hour = 00 - 23, minute and second: 00 - 59). Any deviation from this format will cause a parse exception.
When a date/time value is converted to an integer or vice-versa, a 64-bit offset in seconds from the start of the "epoch" is used for the conversion. Qore's "zero date" (the start of Qore's "epoch") is January 1, 1970 UTC. When calculating second offsets from this date, a 64-bit integer is used.
Relative dates (durations) are normally used for date addition and subtraction. See Date/Time Arithmetic for more information.
Internally, durations are stored as a set of seven discrete signed integer values, one each for years, months, days, hours, minutes, seconds, and microseconds.
There are 3 different formats understood by the Qore parser for describing literal durations in Qore as follows:
750ms
; Qore-specific)P3DT21H
; based on ISO-8601)P0001-03-00T00:00:04
; based on ISO-8601)A single relative date/time value (or a duration) may be specified as follows (note that this format is specific to Qore and not based on ISO-8601):
<integer><date component specifier>
Examples:
250ms:
250 milliseconds30s:
30 seconds2m:
2 minutes19.1s
: 19 seconds and 100 millisecondsSuch values are recommended to give to functions and methods taking a timeout value as the units are then clear in the source code (whereas if an integer is given, it may not be clear that the function or method expects a value in milliseconds, for example); for example:
is clearer than the alternative with an argument given as a value in implied milliseconds to the Queue::pop() method:
Date Specifiers For Single Values For Relative Dates (non-ISO-8601 syntax)
Component | Meaning | Example | Description |
Y | Years | 2Y | 2 Years |
M | Months | 3M | 3 Months |
D | Days | 10D | 10 Days |
h | Hours | 15h | 15 hours |
m | Minutes | 25m | 25 minutes |
s | Seconds | 19.1s | 19 seconds and 100 milliseconds |
ms | Milliseconds | 250ms | 250 milliseconds |
us | Microseconds | 21194us | 21194 microseconds |
This and the next duration format for composite relative date/time values are both based on ISO-8601.
This first format has the following syntax:
PnYnMnDTnHnMnS
Each element above is optional, but at least one element must be present. Note that "M"
means months when before the "T"
and minutes when found after the "T"
. The other elements are years, days, hours, and seconds. Fractional values are accepted as well, but these values are always converted to an integer value in the time component with higher precision (i.e. fractional seconds are converted to microseconds, fractional microseconds are ignored), and additionally the values may be negative.
Here are some examples (using qore's -X command-line option to evaluate and expression and print out the result):
"u"
charater indicating microseconds is a deprecated Qore-specific extension to ISO-8601; use fractional seconds insteadThe second ISO-8601-based format for specifing complex durations with multiple time units has the following syntax:
PYYYY-MM-DDTHH
:mm:SSThis format is more limited than the first format, in that all values must be non-negative, and furthermore, all values must be present (although they may be zero).
Here are some examples of the second format (equivalent to the first examples):
Comparisons with two relative date/time values are made with normalized representations of each component of the date/time value. Because the actual value of a relative date/time value only makes sense when used with an absolute date value (ex: adding 1M
to an absolute date value will result in a different number of days being added depending on the month and day of the absolute date value operand), comparisons of relative date/time values with mixed day, month, and year components must be based on approximations. When mixing day, month, and year components, the following approximations are used:
1D
== 24h
)1M
== 31D
)365D
== 1Y
)These assumptions try to make sense of expressions like:
45D > 1M
for example. Month lengths can range from 28 to 31 days, therefore while the expression:
30D < 1M
will be evaluated as True, when adding 30D
to an absolute date value, the result could be less than adding 1M
(for example, when the operand is an absolute date in February).
<0feba023ffdca6291>
"binary"
NULL
value and can only be accessed directly as an immediate value with the keyword NULL. Note that NULL is not equivalent to NOTHING."NULL"
The keyword NULL stands
for the SQL NULL value.
prompt% qore -X 'exists NOTHING' False
"nothing"
The keyword NOTHING represents
no value.
Boolean, string, integer, date, floating point, and arbitrary-percision numeric data types can be freely converted from one type to the other, although data loss is possible depending on the conversion (particularly when converting to the boolan type as only two possible values are supported).
The special types NULL and NOTHING are not equivalent and are generally not automatically converted to or from any other type.
When date types are converted from strings, any of the following formats can be used: "YYYYMMDDHHmmSS[.us][Z|+-HH[:MM[:SS]]]"
, "YYYY-MM-DD HH:mm:SS.us"
, "YYYY-MM-DDTHH:mm:SS"
, "YYYY-MM-DDTHH:mm:SS[.us][Z|+-HH[:MM[:SS]]]"
, and most reasonable combinations thereof. If the time zone component is missing, then the local time zone will be assumed (see Time Zone Handling).
When dates are converted to and from integer, floating-point, and arbitrary-percision numeric values, the a 64-bit second offset from January 1, 1970 in the local time zone is used for the conversion. For example
gives 1136073600
(regardless of the local time zone the date is in). This is for backwards-compatibility with Qore before time zone support was available; to get the second offset of a date from 1970-01-01Z
(i.e. the true epoch offset), call get_epoch_seconds() instead.
When an expression requires a certain data type and the source data type cannot be converted to the desired data type, the default value for the desired data type will be used. The default values are given in Basic Data Types.