Appendix A. Primitive types

A finite sequence of Unicode characters.

Represents the false and true concepts used in mathematical logic.

The valid values are the strings false and true.

Case is ignored by the engine, so for example False and FALSE also valid values. However the server will always return lower case values.

For backwards compatibility with older versions of the engine, the values 0 and 1 are also accepted. The value 0 has the same meaning than false, and 1 has the same meaning than true. Try to avoid using these values, as support for them may be removed in the future.

Represents the mathematical concept of integer number.

The valid values are finite sequences of decimal digits.

Currently the engine implements this type using a signed 32 bit integer, so the minimum value is -2³¹ (-2147483648) and the maximum value is 2³¹-1 (2147483647).

However, there are some attributes in the system where the range of values possible with 32 bit isn’t enough. In those exceptional cases the engine uses 64 bit integers, in particular for the following attributes:

For these exception cases the minimum value is -2⁶³ (-9223372036854775808) and the maximum value is 2⁶³-1 (9223372036854775807).

Represents the mathematical concept of real number.

Currently the engine implements this type using 32 bit IEEE 754 single precision floating point numbers.

For some attributes this isn’t enough precision. In those exceptional cases the engine uses 64 bit double precision floating point numbers, in particular for the following attributes:

Represents a date and time.

The format returned by the engine is the one described in the XML Schema specification when requesting XML. For example, if you send a request like this to retrieve the XML representation of a virtual machine:

GET /ovirt-engine/api/vms/123
Accept: application/xml

GET /ovirt-engine/api/vms/123
Accept: application/xml

The response body will contain the following XML document:

<vm id="123" href="/ovirt-engine/api/vms/123">
  ...
  <creation_time>2016-09-08T09:53:35.138+02:00</creation_time>
  ...
</vm>

<vm id="123" href="/ovirt-engine/api/vms/123">
  ...
  <creation_time>2016-09-08T09:53:35.138+02:00</creation_time>
  ...
</vm>

When requesting the JSON representation the engine uses a different, format: an integer containing the number of seconds since Jan 1^st 1970, also know as epoch time. For example, if you send a request like this to retrieve the JSON representation of a virtual machine:

GET /ovirt-engine/api/vms/123
Accept: application/json

GET /ovirt-engine/api/vms/123
Accept: application/json

The response body will contain the following JSON document:

{
  "id": "123",
  "href="/ovirt-engine/api/vms/123",
  ...
  "creation_time": 1472564909990,
  ...
}

{
  "id": "123",
  "href="/ovirt-engine/api/vms/123",
  ...
  "creation_time": 1472564909990,
  ...
}