OpenText Analytics Database 26.2.x – Date/time literals

Sql-Reference: Time zone values

Mon, 01 Jan 0001 00:00:00 +0000

OpenText™ Analytics Database attempts to be compatible with the SQL standard definitions for time zones, however, the SQL standard has an odd mix of date and time types and capabilities. Obvious problems are the following:

Although the DATE type does not have an associated time zone, the TIME type can. Time zones in the real world have little meaning unless associated with a date as well as a time, since the offset can vary through the year with daylight-saving time boundaries.
The database assumes your local time zone for any data type containing only date or time.
The default time zone is specified as a constant numeric offset from UTC. It is therefore not possible to adapt to daylight-saving time when doing date/time arithmetic across DST boundaries.

To address these difficulties, OpenText recommends using Date/Time types that contain both date and time when you use time zones. OpenText recommends that you do not use the type TIME WITH TIME ZONE, even though it is supported it for legacy applications and for compliance with the SQL standard.

Time zones and time-zone conventions are influenced by political decisions, not just earth geometry. Time zones around the world became somewhat standardized during the 1900's, but continue to be prone to arbitrary changes, particularly with respect to daylight-savings rules.

The database currently supports daylight-savings rules over the time period 1902 through 2038, corresponding to the full range of conventional UNIX system time. Times outside that range are taken to be in "standard time" for the selected time zone, no matter what part of the year in which they occur.

Example	Description
`PST`	Pacific Standard Time
`-8:00`	ISO-8601 offset for PST
`-800`	ISO-8601 offset for PST
`-8`	ISO-8601 offset for PST
`zulu`	Military abbreviation for UTC
`z`	Short form of `zulu`

Sql-Reference: Day of the week names

Mon, 01 Jan 0001 00:00:00 +0000

The following tokens are recognized as names of days of the week:

Day	Abbreviations
SUNDAY	SUN
MONDAY	MON
TUESDAY	TUE, TUES
WEDNESDAY	WED, WEDS
THURSDAY	THU, THUR, THURS
FRIDAY	FRI
SATURDAY	SAT

Sql-Reference: Month names

Mon, 01 Jan 0001 00:00:00 +0000

The following tokens are recognized as names of months:

Month	Abbreviations
JANUARY	JAN
FEBRUARY	FEB
MARCH	MAR
APRIL	APR
MAY	MAY
JUNE	JUN
JULY	JUL
AUGUST	AUG
SEPTEMBER	SEP, SEPT
OCTOBER	OCT
NOVEMBER	NOV
DECEMBER	DEC

Sql-Reference: Interval literal

Mon, 01 Jan 0001 00:00:00 +0000

A literal that represents a time span.

Syntax

[ @ ] [-] { quantity subtype-unit }[...] [ AGO ]

Parameters

@: Ignored
- (minus): Specifies a negative interval value.
quantity: Integer numeric constant
subtype-unit: See Interval subtype units for valid values. Subtype units must be specified for year-month intervals; they are optional for day-time intervals.
AGO: Specifies a negative interval value. AGO and - (minus) are synonymous.

Notes

The amounts of different units are implicitly added up with appropriate sign accounting.
The boundaries of an interval constant are:
- 9223372036854775807 usec to -9223372036854775807 usec
- 296533 years 3 mons 21 days 04:00:54.775807 to -296533 years -3 mons -21 days -04:00:54.775807
The range of an interval constant is +/– 2⁶³ – 1 microseconds.
The interval fields are additive and accept large floating-point numbers.

Examples

See Specifying interval input.