As of version 07.20.3213, Virtuoso supports
xsd:dateTime values both with and without timezone information, i.e., both "timezoned" and "timezoneless".
Some traditional relational databases keep all values of
DATETIME type as combination of time and timezone data.
Others treat all time values as if they're in a single timezone (which might be specified by configuration, or inferred from local environment), which may mean conversion of submitted values which include timezone information or simple omission of that information upon storage.
In RDF, incoming triples may contain literals of types like
xsd:dateTime with arbitrary values matching ISO 8601, and this standard makes inclusion of timezone optional, i.e., both timezoned and timezoneless values may be included.
This mix makes it necessary to handle both "timezoned" and "timezoneless" datetimes inside one database. Virtuoso servers support this starting from version 07.20.3213.Important: the use of timezoneless datetimes may result in subtle errors in data processing. Applications that worked fine with timezoned datetimes may work incorrectly when timezoneless datetimes are used. Such application errors may stay unnoticed during local testing and only be revealed after worldwide use.
To stay on safe side, the use of timezoneless datetimes remains blocked with databases created pre-07.20.3213, even after the server executable is upgraded, so old applications will continue to work as before. When developing new applications, please pay attention to the check-list at the end of this section.
Different applications may require different behavior when input data contains timezoneless values.
In some cases, it is better to simply
CAST all values to timezoned than to upgrade existing application code.
Virtuoso offers five different modes of support for timezoneless values.
The mode is selected by setting the "
" parameter in
[Parameters] section of
This should be set before creating the database and the set value is stored in the database.
After database is created, an attempt to change the mode by changing the setting in the
virtuoso.ini, will have no effect and the
virtuoso.log will contain a warning about mismatch between setting in the
virtuoso.ini file and the database file.
The possible variants are:
|Never use timezoneless, as it was in old databases. Always set local timezone on parsing strings if no timezone specified. An attempt to set timezoneless by calling function forget_timezone() will signal an error. Timezoneless values still may come from outside as deserializations of timezoneless DATETIME values, serialized by other database instances, but not in any other way.|
| ||When parsing strings, set timezoneless if ISO format tells so.|
| || Set timezoneless always, exception when the parsed string contains explicit timezone or when RFC requires the use of GMT or when timezone is set by the function adjust_timezone(). This is default for new databases if |
| || Never use timezoneless. Always set local timezone on parsing strings if not timezone specified. An attempt to set timezoneless by calling function forget_timezone() will signal an error. Timezoneless values still may come from outside as deserializations of timezoneless DATETIME values, serialized by other database instances, but not in any other way. The difference with |
| || On parsing string, set timezone to GMT if no timezone was specified. However, timezoneless can be set by calling function |
For most new applications, we recommend
as the second-best.
Traditional SQL strings are of format "
YYYY-MM-DD hh:mm:ss" with optional decimal fraction at the end and then optional tinmezone data.
Depending on software, the timezone can be specified as "timezone offset", i.e., the difference with GMT in minutes, or as "timezone label", i.e., an identifier of timezone in special system dictionary that contains not only an offset in minutes but also information about daylight saving changes of the offset.
Virtuoso does not support timezone labels, only numerical timezone offsets. Depending on the system, notation without timezone data at the end may mean timezoneless value or, more probably, the value in some "default" timezone, such as the server's local timezone or GMT.
ISO 8601 introduced format "
YYYY-MM-DDThh:mm:ss", with "
T" character between the "date" and "time" parts.
It also prescribed an unambiguous difference between timezoneless and timezoned values: an absent timezone means a timezoneless value.
The timezone offset is written as "
+hh:mm" or "
-hh:mm", the "
+00:00" is usually shortened to "
Oracle Java may use 1 to 4 digits without delimiting "
:"; in that case, 1 or 2 digits mean whole hours whereas 3 or 4 digits mean 1 or 2 digits of hour and two digits of minutes.
For historical reasons, "
-00:00" notation differs from "
+00:00" and means timezoneless, not GMT datetime.
ISO 8601 explicitly warns that comparison of timezoned and timezoneless datetime is not always possible.
Valid timezones vary from
+14:00; the fact that the span can exceed 24 hours may not be immediately obvious.
Nevertheless, storing rows in a database table require some unambiguous order; any order is OK as long as it does not break the rules and common sense, but it should be well-defined.
Virtuoso's ordering for a mix of timezoned and timezoneless datetimes is very simple:
integer is_timezoneless (in dt datetime)
integer timezone (in dt datetime [, in ignore_tzl integer])
datetime adjust_timezone (in dt datetime, in tz_offset integer [, in ignore_tzl integer])
datetime dt_set_tz (in dt datetime, in tz_offset integer)
datetime forget_timezone (in dt datetime [, in ignore_timezone integer])
datetime now ()
datetime rdf_now_impl ()
datetime getdate ()
datetime get_timestamp ()
datetime current_timestamp ()
then the time has local timezone offset (as it was set at the time of last server start); otherwise it is timezoneless.
datetime curdatetime ([in fraction_microseconds integer])
now(), but fractional part of seconds can be adjusted by providing the number of "microseconds" as the argument.
datetime curdatetimeoffset ([in fraction_microseconds integer])
curdatetime(), but the returned datetime is in GMT timezone.
datetime curutcdatetime ([in fraction_microseconds integer])and
datetime sysutcdatetime ([in fraction_microseconds integer])
curdatetime(), but the returned datetime is in GMT timezone.